Celestin Apprentice 5/Apprentice-Release5.iso/Information/THINK C Digest/1992/92-05

Text File | 1995-12-31 | 144KB | 4,214 lines

Path: ucivax!gateway
From: [e-mail] (TJ Leone)
Subject: Apple Event Object Support Library
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 2
Date: 1 May 92 20:38:34 GMT

Anybody know of an ftp site that has the Apple Event Object Support Library Developer
Notes?










Path: ucivax!gateway
From: [e-mail]
Subject: (none)
Message-ID: <[e-mail]>
X-Mailer: SCO System V Mail (version 3.2)
Newsgroups: fa.think-c
Lines: 35
Date: 3 May 92 03:15:15 GMT

From halifax  Sat, 02 May 92 22:27:23 EDT
To: [e-mail]
Subject: HELP!!! My program died!!
From: admiral.uucp![e-mail] (Nathan Neulinger)
Message-ID: <[e-mail]>
Date: Sat, 02 May 92 22:27:23 EDT
Organization: The Grid/Waffle BBS, 203-661-2873, -1279, -0450, -2967

I don't know what I did to it... but it just plain don't work no more!

Te program I am referring to is a Fractal Image Genertor that I am
working on... It was working GREAT for a while... I even got it to print
out in full color... but now it doesn't work... I am getting alot of Odd
Address errors... and also illegal instruction errors... it's weird... I
cannot seem to find what the problem is...

I don't use alot of handles, so I doubt that it would be a problem with
them... I also give the program plenty of memory, 800K segment... and my
code segments are small... does anyone have any idea what might be
causing it... PLEASE email me if you have any suggestions as to how I
might alleviate this dreadful problem - I need this program to work for
my final project for my Advanced C Programming class....

BTW - I am using Think C 5.0 under 7.0 on a MacPlus with 4MB....

Nathan Neulinger
admiral![e-mail]

Thanks Alot"!!!

--
admiral![e-mail] (Nathan Neulinger) <uunet!admiral!halifax>
The Admiral's Public UNIX - Greenwich, CT - System Administrator: Doug Fields
(HST/V32) [phone] -- (PEP/V32) -1279 -- (V32) -0450 -- (V29/MNP6) -2967
>FREE!< Unix shell accounts, Usenet access, and Internet-style mail available










Path: ucivax!gateway
From: [e-mail] ("Mr. Neb")
Subject: (none)
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 21
Date: 3 May 92 10:18:19 GMT


    In my application, I am using the CommToolBox to handle all of the
communications needed in my program.  I have the code put in correctly, but
the part that does not mesh is how the three types of managers work together.
Specifically the connection manager with the terminal manager.

    If the connection manager sees some data coming in, how does it let
me (or the terminal manager) know that there is some data to be displayed on
the terminal manager's window?

    My idle procedure is in place, and I have seen the connection manager
routines to read and write data.  But from what I can tell, there is not
a way for the connection manager to say "Hey, Dude! Got some narley bits for
you coming in off of the serial port..."

    What am I missing?


    Let me know if you know, I would appreciate it...

    [e-mail]










Path: ucivax!gateway
From: [e-mail] (Hal Zabin)
Subject: FSRead into a structure...
Message-ID: <[e-mail]>
X-Mailer: LeeMail 1.2
Newsgroups: fa.think-c
Lines: 48
Date: 3 May 92 19:28:59 GMT


Please respond to: [e-mail]

<=====-------------------------------=====>
Dr. Hal B. Zabin
Max-Planck-Institut fr molekulare Genetik
Abteilung Trautner
1000 Berlin 33
Germany
<=====-------------------------------=====>

(This file must be converted with BinHex 4.0)

:#P4)58j,,QKPE(!!9%9B9(4dH(3!!!!!"JF!!!!!DI&8D'8JCQpXE'phD@jR)'0
[C'8JBfpZG'&TER-JB5"LG@FJD@iJFQ9KC'PZCb"K)(4PH(3JCQPXC5"TER4[)'%
JBfKKFQ&MG'9b$@*eCQCPFL!SGfKTBfJJDA-JF'&bG#"[CL"K)(0dFR9MG(9bC5N
Z)&4SC5"LG@FJDA-JC'9cBh*TBQ9N)'&d)(4SC5"PEQ3JEfB0G'KP)'0[C'8JFf9
RE@9ZG#iJ55"hEh9XC#"KF("bC@0TBA4P)'&ZH5"TC'9KFb"KERP[EQ8JE@&j)'K
KGQ8JEfiJGfKKG!e*)'&Y)'4[D@jR)(GbEfjR)'KPFQ8Z$3d0$@4PCQPZDA4TEfi
JEfBJFh4bG@0dGA*P)'PZBfaeC'9N)'PZ)("bEfGbB@dYGfPNC5"SC@&NCA)JCQP
XC6S0$A0dFR9MG#"$8h4eCQCl$3PMD'&b)#TdD'96G()l#5mU)'0SBA*KBh4PFL"
LG@CQCA)J+Lm0#@a[EQF*G'KP6'9ZCh4S1`N[+L"MGA*bC@jd)'aPEQGdD#"[CL"
dD'96G()J+Lm0#@a[EQF*B90THQ8l#5mU)'pbD@GTEQ&X)'&XE'pMBA4TEfiJFfP
kC5"[CL"dD'96G()J+Lm0I6X0)f4PCQPZC5"$D'&b8h4eCQB*Fh4bG@0d)%06G(9
QCJedHA"PC'9Q)%0SBA*6G(9QCJNU3e03G()l$A4jF'9NC@BJ3e03G()*+N065'&
ZC'aP1`d0$@*KFf96CA%JDA-JC'9ME'&bC@3JBA-JB5"RE'pLB@`J3e03G()JD@i
JB@iJD@jME(9NC@3JCQPXC6S03e03G()*EQ9h8f9a,'*KFf96CA%XB@aTCfj8H(3
l$3d08'&bG#"[CL!LCQPXC5jM)L"hD'PMD#"cD'peE'3JFQ9KC#"K)(4PH(3JCQP
XC5"K)("eG#"dD'8JG'9iG#"TER4[$@*KFf96CA%Y2R4SC90dFL!SF'&bG#"[CL"
KBQpfC5"cG(*eBh4eFQ8T1Jd0E'pZCb"5C@&N5@j'D@aP+(C[D@3T$AX0#@a[EQF
JBfpeER3XG'KP6'9ZCh4S1`d*D@jd)&4SC8PZ8Q9Q1`d*$3PTCL!S4P02F'9Z+(4
SC9*PF'aj,QC1B@eP,(4SC9*PF'aj,RC5C@C1G@dX*P4SC8PZ8Q9Q+5N0#3P%Ede
PFh0KCf8S)Pa`4A*bEh)JEh"PEQPZCb"QD@aP)LNl$3P(CA4&6dBS9'KP5@j5C@B
X*R4SC8aPEQGdD#Nl#5mU)'GPG#"XC@jRG'JJ+Lm0$3PMEh9ZG$edD'9-C@jRG'J
l$3d*,bSJB@aXEf0KG'8JE@9YEh*j)#S[$3PLBA0P8f9a,6jK8fPkC6dSG'KP6'9
ZCh4S+5TcDATPEfBSBfKKFLNl$3PLBA0P8f9a,6jdD'96G()J25!SBfKKFLST6Q9
h8(4b+'*KFf96CA%Y2Q&6DATP+6X*$3PTCL!S6@9Y4A*bEh)S+5N*4'p0CA0cB@G
P+#*FF%9bFQpb)'PZ)'&XE'pMBA4TEQFJBQ&cC90PF5dqG'KP8h4b)LNl$3N0#5m
U+LSU+L"38Np#6%90)%a*6N8J4Np-6%pA8b%K)5%K)5%K)#SU+LSU+LSU+LSU+LS
U+LSU+LS[$3PTCL!S4P05C@&N+&4SC8PZ8Q9Q,#CMEh9ZG#aLBA0P8f9a,6jdD'9
6G()T+3d*$3N*4'p0CA0cB@GP+#*FF%9bFQpb)'PZ)(*PB@4TEQFJCQPXC5)T1`d
*D@BJ+%C63fa[Ff8S9'KP5@j5C@BT+3d*#84[6@9cFf&RC5JLA("&FR*[FL"TEL"
ME'pcD@jR)'CTE'8L+6X0$3eAD'9Z)%NJFR9Z)(4SDA-JF(*[Ch*KE5"dEb"dD'P
c)("[D@jd,#"[EQaj)'G[BQ*XC@4j,@G[EfXJCfpPFb"TER4[)!eLBA0P8f9a,6j
dD'96G()JBA3JG'KP)%C68Q9KC#"XD@jP,L""ERNJD@4PBA-r)&4SB@jVFb"K)'a
[G#`0$8KKE#"#,L"DB@*TEJeD38**6N"5@Le#49*-58iZ69"(,N4&&QB!!!:












Path: ucivax!gateway
From: [e-mail]
Subject: (none)
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 59
Date: 3 May 92 19:35:34 GMT

I just sent a version of this as an enclosure, and realize that it will
probably be more trouble than it is worth to read it as sent. Therefore
I am sending it again as a single text file. Sorry about the confusion!

The following code contains a bug in reading a text file into a character
buffer (which is part of a structure). The bug is described at the end of
the code segment. I would appreciate any ideas anyone may have on what
I am doing wrong here.



definition of structure included in program-wide header file:

struct CStuff{
    char *theStr;    /* character buffer */
    long    theLength;    /* current length of theStr */
    long    aSize;    /* original allocation size of theStr */
};
#define CharStuff    struct CStuff
typedef CharStuff    *CSPtr;
typedef CSPtr    *CSHandle;


baseSeq is declared as a global CSPtr in an included file:
CSPtr    newSeq,baseSeq,alignTxt;


Part of "file.c" which should read a text file a put the text into
baseSeq->theStr (part of above structure):

long ReadInFile(void)
{
    long count,theLength;
    int TheInRef;

    if (FSOpen(theReply.fName,theReply.vRefNum,&TheInRef))
        DoMessage("\pError opening file");
    GetEOF(TheInRef,&theLength);    /* get length */

    count=theLength;

    /* allocate memory */
    baseSeq->aSize=(theLength)*sizeof(char);
    baseSeq->theStr = (char*)NewPtr(baseSeq->aSize);
    if (MemError())    DoMessage("\pError in allocating baseSeq->theStr");

    /***** PROBLEM LINE FOLLOWS!!!!!!!! *******************/
    if (FSRead(TheInRef,&count,baseSeq->theStr))

        DoMessage("\pError in reading file");
    if (FSClose(TheInRef))
        DoMessage("\pError in closing file");


When I run this program to this point, only gobbledy-gook goes into
baseSeq->theStr at the FSRead line. Any ideas? Thanks a lot,

Hal B. Zabin
[e-mail]










Path: ucivax!gateway
From: [e-mail] (Bob Beason)
Subject: Problem in SANE.h?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
X-VMS-To: IN%"[e-mail]"
Lines: 9
Date: 4 May 92 11:48:42 GMT

I was remaking ANSI-A4 last night to include FPU support.  After changing
the line in ansi_config.h to commen out the nofloat statement, I tried to
remake.  The following line in SANE.h kept producing a syntax error:
    if sizeof(double) == 12
I tried eveything I could think of, but nothing worked.  I am using
THINK C 5.02 and System 7.  Does anyone have any ideas?
Thanks in advance.
Bob Beason
[e-mail]










Path: ucivax!gateway
From: [e-mail] ("Kenneth B. Kirksey")
Subject: Profile Problem
Full-Name: Kenneth B. Kirksey
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 11
Date: 4 May 92 19:58:24 GMT


    I was playing around with the profiler today and I had a strange
problem. After i was finished profiling, I removed all the profile
calls from my source and removed the Profile library from my project.
When I tried to run the project again, it kept giving me link errors
saying it couldn't find _proflie_. I tried removing the objects and
rebuilding the project, but it still gave me the same error. It would
only run if I included the profile library again. Anonyone have andy
ideas why it would do this?

                             Ken










Path: ucivax!gateway
From: [e-mail] ("Russell S. Finn")
Subject: Re: Profile Problem
Message-ID: <[e-mail]>
In-Reply-To: Your message of "04 May 92 19:58:24 GMT."
             <[e-mail]>
Newsgroups: fa.think-c
Lines: 17
X-Mts: smtp
Date: 4 May 92 21:18:23 GMT

>     I was playing around with the profiler today and I had a strange
> problem. After i was finished profiling, I removed all the profile
> calls from my source and removed the Profile library from my project.
> When I tried to run the project again, it kept giving me link errors
> saying it couldn't find _profile_. I tried removing the objects and
> rebuilding the project, but it still gave me the same error. It would
> only run if I included the profile library again. Anonyone have andy
> ideas why it would do this?

Your project was compiled with the "Profiler" option on, which causes
the compiler to insert calls to a function called "_profile_" at the
beginning of each function in your code.  You'll need to turn this
project option off again if you want to completely remove profiling
from your program.

-- Russell S. Finn
[e-mail]










Path: ucivax!gateway
From: [e-mail] ("Kenneth B. Kirksey")
Subject: New Dialog Routines
Full-Name: Kenneth B. Kirksey
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 47
Date: 5 May 92 00:10:53 GMT


    I'm having a little problem with the SetDialogTracksCursor function
documented in Tech Note 304. Here's a chunk of my dialog handler:

+++++++++++++++++++++++++++++++++++++
int HandleConvertDialog (void)
{
    int     itemHit,
            dialogDone = FALSE;

    int     itemType;                   /* Vars for getting and setting       */
    Rect    itemRect;                   /* dialog item values.                */
    Handle  itemHandle;

    ModalFilterProcPtr  standardProc;

    /*-------------------------------------------------------------------------+
    | Set Up The Dialog using those cool System 7 Dialog Routines.             |
    +-------------------------------------------------------------------------*/
    GetStdFilterProc(&standardProc);
    SetDialogTracksCursor(gConvertDialog, FALSE );
    SetDialogDefaultItem(gConvertDialog, rOkButton);
    SetDialogCancelItem(gConvertDialog, rCancelButton);

    /*-------------------------------------------------------------------------+
    | Show the dialog window.                                                  |
    +-------------------------------------------------------------------------*/
    ShowWindow (gConvertDialog);

    /*-------------------------------------------------------------------------+
    | Dialog Event Loop.                                                       |
    +-------------------------------------------------------------------------*/
    while (dialogDone == FALSE)
    {
        ModalDialog (standardProc, &itemHit);
        switch (itemHit)

+++++++++++++++++++++++++++++++++++++

Now the SetDialogDefaultItem and the SetDialogCancelItem functions work as
advertised. No problem there. The SetDialogTracksCursor, however, doesn't.
When I open my dialog and pass the pointer over one of the two edit text fields
in the dialog, it doesn't change to the I-beam like it should. Anyone have
any ideas why it's not working?  Many thanx in advance.

                                  Ken











Path: ucivax!gateway
From: [e-mail] ("Mr. Neb")
Subject: Keypress causes mac to beep, but no event is generated...
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 127
Date: 5 May 92 01:33:59 GMT


    I have a very strange bug.  Somewhere in the following code,
something happens which makes my application not accept a keypress
when running.  All I get are beeping sounds whenever a key is pressed.
I created a file to output every event, giving all of the fields like
what, where, etc.  The keyDown event is never seen by my application.
When I go back to Think C (or anything else), there is no problem.
This thing is really bugging me, and I have spent so much time with
it that I do not know what could be going wrong (even if it is looking
me in the face ;-).  If anyone sees a problem in this code that can
be my bug, or if there is somewhere else I should check, please let
me know so that I can get some sleep...

    The mac beeps on any keypress whether I build an application
or if I run it from Think C...

void main(){
    Boolean cmndown, shiftdown, ctrldown;
    char *s;
    int c, d;
/*
    Initialization routines...
*/
    initialize(FALSE);
    UnloadSeg(initialize);

    for (;;) {

        doIdle();

        WaitNextEvent(everyEvent, &myEvent, 0L, 0L);

        HandleEvent();

    } /* end of main event loop */
}

void initialize(Boolean aeGenerated){

/* Will be true if we got the init command as an apple event. */

    if (!aeGenerated){
        ToolBoxInit();

        initGlobals();
        canWaitNext = IsWNEIsImplemented();
        if (HasAppleEvents){
            InitMyAppleEvents();
        }
        initCTB();
    }


    SetUpMenus();

    StartCTB();
}

void ToolBoxInit(void){

    InitGraf(&qd.thePort);
    InitFonts();
    FlushEvents (everyEvent,0);
    InitWindows();
    InitMenus();
    TEInit();
    InitDialogs(quit);
    InitCursor();

    InitCRM();
    InitCTBUtilities();
    InitCM();
    InitTM();

    MoreMasters();
    MoreMasters();
}

void initCTB(void){
    OSErr err;

    termWindow=GetNewWindow(128,NIL,(WindowPtr)-1);

    SetPort(termWindow);

    termRect= termWindow->portRect;

    gTerm=NIL;
    gConn=NIL;
    gBuffer=NIL;

    CRMGetIndToolName(classTM,1,toolName);
    termID=TMGetProcID(toolName);
    gTerm=TMNew(&termRect,&termRect,tmSaveBeforeClear,termID,termWindow,mySendProc,myCacheProc,myBreakProc,NIL,myEnvironsProc,0,0);

    connSizes[cmDataIn]=1024;
    connSizes[cmDataOut]=1024;
    connSizes[cmCntlIn]=0;
    connSizes[cmCntlOut]=0;
    connSizes[cmAttnIn]=0;
    connSizes[cmAttnOut]=0;

    CRMGetIndToolName(classCM,1,toolName);
    connID=CMGetProcID(toolName);
    gConn=CMNew(connID,cmData /* flags*/,connSizes,0,0);

    gBuffer=NewPtr(1024);

}

void StartCTB(void){
    int result;
    Point wheretoput={50,50};

    result=CMChoose(&gConn,wheretoput,myIdleProc);

    DoInitiate(); // initiates the connection
}



    Thanks, I appreciate your time and patience...

    Dave

    [e-mail]











Path: ucivax!gateway
From: [e-mail] ("Mr. Neb")
Subject: Re: New Dialog Routines
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 16
Date: 5 May 92 02:03:00 GMT

    SetDialogTracksCursor(gConvertDialog, FALSE );

From Tech Note #304

/* Tells the Dialog Manager that there is an edit line in this dialog, and */
/* it should track and change to an I-Beam cursor when over the edit line */
pascal OSErr SetDialogTracksCursor(DialogPtr theDialog, Boolean tracks)
    = { 0x303C, 0x0306, 0xAA68 };

    To me, it looks like you're telling the Dialog Manager _NOT_ to
track the cursor by sending it the FALSE value.  You probably just need
to send it a TRUE value...

    Dave Nebinger

    [e-mail]










Path: ucivax!gateway
From: [e-mail] (Bob Beason)
Subject: #if bug in THINK C 5.0?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
X-VMS-To: IN%"[e-mail]"
Lines: 6
Date: 5 May 92 02:05:18 GMT

I have been trying to use the #if statement in THINK C 5.02, but keep getting
a syntax error or the statement doesn't work.  It makes no difference whether
I use an expression or a constant, the results are the same.  Is this a
bug?
Bob Beason
[e-mail]










Path: ucivax!gateway
From: [e-mail] ("Kenneth B. Kirksey")
Subject: More Dialog Fon
Full-Name: Kenneth B. Kirksey
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 13
Date: 5 May 92 03:09:59 GMT


The question that I posted earlier had a mistake in the code. The line

SetDialogTracksCursor(gConvertDialog, FALSE );

Should read

SetDialogTracksCursor(gConvertDialog, TRUE);

I tried it both ways for funzies, and it still didn't work. Sorry for
the confusion.

                                     Ken










Path: ucivax!gateway
From: [e-mail]
Subject: (none)
Message-ID: <[e-mail]>
X-Mailer: SCO System V Mail (version 3.2)
Newsgroups: fa.think-c
Lines: 44
Date: 5 May 92 03:58:29 GMT

From halifax  Mon, 04 May 92 16:55:26 EDT
To: [e-mail]
Subject: Fractal Generator - Errors/Etc.
From: admiral.uucp![e-mail] (Nathan Neulinger)
Message-ID: <[e-mail]>
Date: Mon, 04 May 92 16:55:25 EDT
Organization: The Grid/Waffle BBS, 203-661-2873, -1279, -0450, -2967

Ok, to the few of you that have helped me out.. Thanks alot... Many of
you asked for more specific information as to the errors I was
experiencing...

One: The program runs fine if I let it sit there... But if I got to
select another window of mine (of this program's), i get a System Erro
#25 at 00408496 which is _StuffHex+018E

Two: If I choose a particular menu command - Generate or Redraw... i get
a System Error #11 - Misc. Exception Error

Three: (Not important at the moment) For some reason, I could not get one
of my Hierarchical menus to load rpoperly... I could get two of them to
appear, but this one menu command, no matter what I did, it wouldn't
bring up the submenu... I had all the fields set properly in ResEdit
(2.1).. and loaded it with InsertMenu( ..., hierMenu);

I am running Think C 5.0.2 (Just upgraded), on a Mac Plus with 4MB... I
am using System 7.0 (not upgraded yet)...

If anyone has any suggestions, please respond... If anyone is interested
in trying to help me out, I could email you a copy of the source code and
the resource file (i'd have to use SADeRez right?).... If you'd take a
look at it.. However, i'd rather not dirtribute the source too much...

Thanks All,
Nathan Neulinger

admiral![e-mail]


--
admiral![e-mail] (Nathan Neulinger) <uunet!admiral!halifax>
The Admiral's Public UNIX - Greenwich, CT - System Administrator: Doug Fields
(HST/V32) [phone] -- (PEP/V32) -1279 -- (V32) -0450 -- (V29/MNP6) -2967
>FREE!< Unix shell accounts, Usenet access, and Internet-style mail available










Path: ucivax!gateway
From: [e-mail] (Eric Slosser)
Subject: (none)
Message-ID: <[e-mail]>
In-Reply-To: [e-mail]'s message of 3 May 92 03:15:15 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 24
Date: 5 May 92 08:56:07 GMT


> ... but now it doesn't work... I am getting alot of Odd
> Address errors... and also illegal instruction errors... it's weird... I
> cannot seem to find what the problem is...

Here's some trouble-shooting advice:
When you get the error (odd-address or ill-instruct), drop into macsbug.
Look at the code around the program counter.  (Using IP or "DM PC-30 60").
Is it coherent 68000 code?  If so, check your compiler settings and make
sure you're not doing something like:
    char *p;
    if ( *((short*)p)==foobar )
(The above hits an odd-addr error on 68000's when p is odd)

If it's not coherent, if the DM command shows the same byte repeated over
and over, or the assembly listing gives a lot of "ORI.B" instructions,
then either code resource got written into (with a bad CopyBits, maybe) OR
one of your routines trashed the stack and RTS'ed into the tall grass.

A simple "WH PC" will tell you which of these is the case.

The above is not intended to be an exhaustive troubleshoot, but let me
know if it helps.











Path: ucivax!gateway
From: [e-mail] (Eric Slosser)
Subject: (none)
Message-ID: <[e-mail]>
In-Reply-To: [e-mail]'s message of 3 May 92 19:35:34 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 7
Date: 5 May 92 09:01:28 GMT


You may be getting garbage when you read the file because you
haven't done:
    err = SetFPos(TheInRef,fsFromStart,0);

Assuming, of course, that all your memory got allocated...











Path: ucivax!gateway
From: [e-mail]
Subject: Removal from list
Via: manadon-engineering-college.ac.uk; Tue, 5 May 1992 11:40:00 +0100
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 1
Date: 5 May 92 13:29:55 GMT

Please remove me from the mailing list... Thanks










Path: ucivax!gateway
From: [e-mail] ("Jamie R. McCarthy")
Subject: Re: (none)
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>; from "[e-mail]" at May 5, 92 3:58 am
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: fa.think-c
Lines: 29
Date: 5 May 92 14:11:32 GMT

> One: The program runs fine if I let it sit there... But if I got to
> select another window of mine (of this program's), i get a System Erro
> #25 at 00408496 which is _StuffHex+018E

Yow.  Sounds like either a jump to someplace inappropriate (you aren't
really using StuffHex, I hope), or just an error in an unnamed ROM
routine.  Probably the latter.  Error 25 is, I believe, QuickDraw
running out of memory.

> Two: If I choose a particular menu command - Generate or Redraw... i get
> a System Error #11 - Misc. Exception Error
>
> Three: (Not important at the moment) For some reason, I could not get one
> of my Hierarchical menus to load rpoperly... I could get two of them to
> appear, but this one menu command, no matter what I did, it wouldn't
> bring up the submenu... I had all the fields set properly in ResEdit
> (2.1).. and loaded it with InsertMenu( ..., hierMenu);

These two may be related.  Keep in mind that the first word of a menu
has to match its ID.  Open any suspect menus in "view as hex" format,
and change that first word if necessary.

Step through with a debugger (Think's, or Macsbug, either one) and
figure out exactly where that System Error #11 occurs.
--
 Jamie McCarthy     Internet: [e-mail]     AppleLink: j.mccarthy
 "A common way to answer a question about C is to 'see what the compiler
  does.'  Clearly C has suffered from being partly defined, then
  implemented." - High C language reference manual, 1987










Path: ucivax!gateway
From: [e-mail] ("Life, God is gracious.")
Subject: leaving
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 2
Date: 5 May 92 16:55:00 GMT

Well, the semester's drawing to a close, and I soon will be leaving this
university... so thanks for the memories (RAM or ROM? 8-) and goodbye.










Path: ucivax!gateway
From: [e-mail] ("Mr. Neb")
Subject: Re:  Keypress causes mac to beep, but no event is generated...
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 13
Date: 5 May 92 20:57:13 GMT

    I have discovered the source of my error.  I had been using
the console to pump information about what was happening in my program
so that I could track it.  Well it seems that the console was taking
my keypresses, and not letting my event routine handle it itself.

    After removing the debugging code, my app started to receive
the keypress events.

    Thanks,

        Dave

    [e-mail]










Path: ucivax!gateway
From: [e-mail] (Sigurdur Darri Skulason)
Subject: need info about vt102 ctb tool
Message-ID: <[e-mail]>
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: fa.think-c
X-Charset: ASCII
Lines: 25
Date: 6 May 92 04:42:08 GMT
X-Char-Esc: 29

I am writing an application which uses the vt102 ctb tool.
However, it has the flaw of only being 7 bit and the icelandic
character set needs 20 extra characters, so I have to use icelandic
characters instead of a number of symbols like [, } etc.
The only way of then showing these symbols would be to switch
back to the us ascii set and then back again.

That however slows down the program quite a bit, but a way to speed things
up a bit might be to use the temporary character sets G2 and G3.

And that is the problem I want to ask about. According to the documentation
these temporary character sets can be used to display one character and
then automatically switch back to the old char set, which seems to be
excactly what I need to. However, there seems to be NO documentation about
how to select these character sets in this temporary way ?!?

Can anyone inform me about how to select them? Or if there is any
better way to bypass this 7-bit limitation? I would really appreciate
any information.

--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
Sigurdur Darri Skulason                                    [e-mail]
Hugsun inc.                                               Fax:[phone]
Laugavegur 59,IS-101 Reykjavik,Iceland
Tel:  [phone]  /  [phone]  /  [phone]  /  [phone]










Path: ucivax!gateway
From: [e-mail] ("Mr. Neb")
Subject: Is everyone getting this?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 13
Date: 6 May 92 16:11:11 GMT


    It seems that someone named King has changed his email address,
but not notified the list.  Whenever I post a letter to the mailing list,
eventually I recieve a notice from a Michael Tillman from Duke that says
that King's email address has been changed, and that I should use the
new address the next time I mail to him.

    Is this only happening to me, or has everyone been getting them?

    Just wondering,

        Dave
        [e-mail]










Path: ucivax!gateway
From: [e-mail] ("Erik A. Johnson")
Subject: Re: Is everyone getting this?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 17
Date: 7 May 92 03:20:39 GMT

[e-mail] writes:
> Whenever I post a letter to the mailing list,
> eventually I recieve a notice from a Michael Tillman from Duke that says
> that King's email address has been changed, and that I should use the
> new address the next time I mail to him.
>
>   Is this only happening to me, or has everyone been getting them?

I haven't gotten anything like that.


Erik A. Johnson        \    Internet: [e-mail]     \       |
------------------------\    AmericaOnline: ErikAJ                   \    --+--
Graduate Student         \--------------------------------------------\     |
Aero/Astro Engineering    \  "Jesus said to him, 'I am the way, and    \    |
University of Illinois at  \  the truth, and the life; no one comes to  \   |
   Urbana-Champaign (UIUC)  \  the Father except through me.'" (Jn14:6)  \










Path: ucivax!gateway
From: [e-mail] ("Erik A. Johnson")
Subject: Re: Is everyone getting this?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 24
Date: 7 May 92 08:12:47 GMT

[e-mail] writes:
> Whenever I post a letter to the mailing list,
> eventually I recieve a notice from a Michael Tillman from Duke that says
> that King's email address has been changed, and that I should use the
> new address the next time I mail to him.
>
>   Is this only happening to me, or has everyone been getting them?

I responded:
> I haven't gotten anything like that.

And about the same time my response got back to me on think-c, I got
a similar message from Michael Tillman at Duke.  Sorry.

So what's the deal?  Someone needs to change this guy's address in the
think-c master address list or something?


Erik A. Johnson        \    Internet: [e-mail]     \       |
------------------------\    AmericaOnline: ErikAJ                   \    --+--
Graduate Student         \--------------------------------------------\     |
Aero/Astro Engineering    \  "Jesus said to him, 'I am the way, and    \    |
University of Illinois at  \  the truth, and the life; no one comes to  \   |
   Urbana-Champaign (UIUC)  \  the Father except through me.'" (Jn14:6)  \










Path: ucivax!gateway
From: [e-mail]
Subject: (none)
Message-ID: <[e-mail]>
X-Mailer: SCO System V Mail (version 3.2)
Newsgroups: fa.think-c
Lines: 29
Date: 8 May 92 03:30:47 GMT

From halifax  Thu, 07 May 92 15:09:00 EDT
To: [e-mail]
Subject: More on the fractal generator...
From: admiral.uucp![e-mail] (Nathan Neulinger)
Message-ID: <[e-mail]>
Date: Thu, 07 May 92 15:09:00 EDT
Organization: The Grid/Waffle BBS, 203-661-2873, -1279, -0450, -2967

I found where a couple of the errors occur... They happen at the end of a
function, where it is about to return to the calling function...

I still have not found any code in my program that is likely to cause
this... I do very little with handles and/or pointers... I have one main
pointer that i use.. I dynamically allocate (using calloc), a two
dimensional array of ints.... However, I check the returns on these
functions...


Again... If anyone has any suggestions, I would appreciate the help...

Also, I f anyone would be willing to look at the source code and try to
find the problem, I have the source, and resources binhexed, so I coul
mail them to you... Drop me a mail if youre interested...

--
admiral![e-mail] (Nathan Neulinger) <uunet!admiral!halifax>
The Admiral's Public UNIX - Greenwich, CT - System Administrator: Doug Fields
(HST/V32) [phone] -- (PEP/V32) -1279 -- (V32) -0450 -- (V29/MNP6) -2967
>FREE!< Unix shell accounts, Usenet access, and Internet-style mail available










Path: ucivax!gateway
From: [e-mail]
Subject: Are you using an IBM mailer?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 10
Date: 8 May 92 07:46:07 GMT

I am using LeeMail on the mac to receive e-mail, and someone seems to be using
an IBM mailer to try and respond to a question I posted. PLEASE STOP! LeeMail
for some reason crashes when an IBM mailer attempts to connect! This has been
going on for about 5 days - if you are using an IBM mailer to try and contact
[e-mail] please stop it!"!!!
Thank you, Hal B. Zabin

[e-mail]
Max-Planck-Institut fuer molekulare Genetik
Berlin, Germany










Path: ucivax!gateway
From: [e-mail] ("Mr. Neb")
Subject: Answers to "Is Everyone Getting This..."
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 9
Date: 8 May 92 16:15:35 GMT


    From the responses that I have gotten, 5 people are recieving the
email that I referred to before (I even got a new one with that posting)
and 5 people are not getting the email about the change in address.

    Quite different, No?

    Dave
    [e-mail]










Path: ucivax!gateway
From: [e-mail] ("Erik A. Johnson")
Subject: Re: Answers to "Is Everyone Getting This..."
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 20
Date: 8 May 92 20:43:45 GMT

Dave,

>     From the responses that I have gotten, 5 people are recieving the
> email that I referred to before (I even got a new one with that posting)
> and 5 people are not getting the email about the change in address.
>
>     Quite different, No?

The only times I got that message were when I sent mail to think-c.
Not for anyone elses posts to think-c.  Is it possible that the daemon
or person that is bouncing the mail is sending it only to the person who
originated the post?


Erik A. Johnson        \    Internet: [e-mail]     \       |
------------------------\    AmericaOnline: ErikAJ                   \    --+--
Graduate Student         \--------------------------------------------\     |
Aero/Astro Engineering    \  "Jesus said to him, 'I am the way, and    \    |
University of Illinois at  \  the truth, and the life; no one comes to  \   |
   Urbana-Champaign (UIUC)  \  the Father except through me.'" (Jn14:6)  \










Path: ucivax!gateway
From: [e-mail] (Sigurdur Darri Skulason)
Subject: Re: Answers to "Is Everyone Getting This..."
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>; from "Erik A. Johnson" at May 8, 92 8:43 pm
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: fa.think-c
X-Charset: ASCII
Lines: 21
Date: 8 May 92 21:41:41 GMT
X-Char-Esc: 29

>
> Dave,
>
> >     From the responses that I have gotten, 5 people are recieving the
> > email that I referred to before (I even got a new one with that posting)
> > and 5 people are not getting the email about the change in address.
> >
> >     Quite different, No?
>
> The only times I got that message were when I sent mail to think-c.
> Not for anyone elses posts to think-c.  Is it possible that the daemon
> or person that is bouncing the mail is sending it only to the person who
> originated the post?

Wery likely since I can say the same, getting this reply when I posted.

--- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- --- ---
Sigurdur Darri Skulason                                    [e-mail]
Hugsun inc.                                               Fax:[phone]
Laugavegur 59,IS-101 Reykjavik,Iceland
Tel:  [phone]  /  [phone]  /  [phone]  /  [phone]










Path: ucivax!gateway
From: [e-mail] (King Rhoton)
Subject: Is everyone...
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 6
Date: 9 May 92 02:31:23 GMT

Yes, I am aware that people are getting this forwarding message.  I have tried
three times to get my old address changed at the think-c host, to no avail.
I am still working on it, but if anyone has any other advice about how to do
it besides sending mail to think-c-request, I'd love to hear from you.
(Besides, changing addresses in the first place was not even my decision....)
King










Path: ucivax!gateway
From: [e-mail]
Subject: File Comparison Utility Script
Message-ID: <"11-May-929:20:56".*[e-mail]>
In-Reply-to: <[e-mail]>
Newsgroups: fa.think-c
Reply-to: "[e-mail] .Roch"@xerox.com
X-NS-Transport-ID: 0000AA0084559F262DCE
Lines: 37
Date: 11 May 92 14:20:09 GMT

I have a question.

Does anyone have a program or code that could compare lines in a document by
field?


    i.e.    Sample output from FileList+

Filename        Size    Version    Date Created        Path
-----------          ----    ------          ----------
------------
Excel 92 Budget    20K            1/5/92            Documents:Excel

Spreads:
Budget for 92        24K            12/31/91        Warped
Drive:Misc
                                    Spreads

I have looked at FileList+ (the most recent version) and XCat, among others.
However, these packages do not seem to have a robust matching algorithm.

When I perform a match, I first check for the same filename and size
(duplicates).  Then I would like to match based on similar names (i.e. to
locate multiple revisions of an application - Word 3.0 vs. Word 4.0).
FileList+ and the other packages I have tried cannot handle the second case.
When it compares filenames, it will sort them alphabetically and therefore
would not pick up on the sample above.

Does anyone have any ideas?


Thanks in advance,

Marissa Henderson
Systems Analyst
Xerox Corporation
[e-mail]










Path: ucivax!gateway
From: [e-mail]
Subject: How to subscribe?
Message-ID: <[e-mail]>
Posted-Date: Mon, 11 May 92 13:15:33 EDT
Newsgroups: fa.think-c
Lines: 8
Date: 11 May 92 17:15:56 GMT

Could someone please tell me how to subscribe to this list?

Phil Calvert

****************************************
* Bitnet: pncsppc@ncsuvax              *
* Internet: [e-mail] *
****************************************










Path: ucivax!gateway
From: [e-mail]
Subject: How to subscribe?
Message-ID: <[e-mail]>
In-Reply-To: [e-mail]'s message of 11 May 92 17:15:56 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 34
Date: 11 May 92 18:37:38 GMT

Here's an old msg that will help.

Put

subscribe

in the msg body (or maybe it's the subject line...oh, shucks, put it
in both. One is bound to work.

                            ---Al

From [e-mail] Thu Feb 27 09:19:36 1992
Return-Path: <[e-mail]>
From: Harald Hanche-Olsen <[e-mail]>
Subject: think c mailing list
Newsgroups: fa.think-c
Date: 27 Feb 92 07:12:58 GMT
To: [e-mail]

   From: Fred Swartz <[e-mail]>
   Newsgroups: fa.think-c
   Date: 27 Feb 92 05:33:22 GMT

   Could you please add me to your think-c mailing list.  Thanks
     -- Fred  ([e-mail])

Nope.  Write to [e-mail], not the list address.

- Harald Hanche-Olsen <[e-mail]>   [phone]
  Division of Mathematical Sciences
  The Norwegian Institute of Technology
  N-7034 Trondheim, NORWAY












Path: ucivax!gateway
From: [e-mail] (Igor Livshits)
Subject: Array of bits?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 9
Date: 12 May 92 23:48:37 GMT

Hello,

Is there a way to create an array of bits in THINK C?

I don't want to waste the memory for
Boolean inactive[180];

Thanks for your help, Igor











Path: ucivax!gateway
From: [e-mail]
Subject: Any small sample code in 'C'?
Message-ID: <[e-mail]>
Posted-Date: Tue, 12 May 92 21:16:28 EDT
Newsgroups: fa.think-c
Lines: 16
Date: 13 May 92 01:16:43 GMT

Hello!  Anyone out there know of any public domain 'C' code that's
available for downloading, and which would be good for a beginner to
tinker around with?  I want to learn 'C' but I don't want to type in those
stupid little programs, that don't do anything useful, one commonly
finds in books on how to learn 'C'.  Preferably, the code should be in
ANSI 'C' and be highly portable (or be written specifically for THINK C).
Thanks in advance for any help.

Sincerely,

Phil Calvert

****************************************
* Bitnet: pncsppc@ncsuvax              *
* Internet: [e-mail] *
****************************************










Path: ucivax!gateway
From: [e-mail] (Nathan Neulinger)
Subject: HOORAY!!!!!!!"!!!
Message-ID: <[e-mail]>
X-Mailer: SCO System V Mail (version 3.2)
Newsgroups: fa.think-c
Lines: 19
Date: 13 May 92 03:31:01 GMT

To all of you out there who have helped with my problems with my
Fractal Generator program... thanks ALOT.... I finaly figured out what the
problem was...

The worst thing was, it had almost nothing to do with pointers or handles or anything like that...

 a bunch of SetPort calls in various locations throughout my program, I fixed the entire problem with crashing...

NOW: I only have two remaining problems:

1. How to speed up color printing - or printing at all... at the moment it is extremely slow...

2. How to write out the graphics data in various file formats

Thanks all...

Nathan
admiral![e-mail]
/s










Path: ucivax!gateway
From: [e-mail] ("Jamie R. McCarthy")
Subject: Re: Array of bits?
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>; from "Igor Livshits" at May 12, 92 11:48 pm
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: fa.think-c
Lines: 24
Date: 13 May 92 12:32:02 GMT

> Is there a way to create an array of bits in THINK C?
>
> I don't want to waste the memory for
> Boolean inactive[180];

Not really;  you have to fudge it.  C has these two conflicting rules:
first, that "x[y]" can always be read as "*(x+y)", and second, that you
can't take the address of a bit field (K&R, 2nd ed., the last sentence
in chapter 6).

The best you can do is to fudge it:

typedef struct {
    unsigned int b00:1,b01:1,b02:1,b03:1,b04:1,b05:1,b06:1,b07:1,
       b08:1,b09:1,b10:1,b11:1,b12:1,b13:1,b14:1,b15:1;
} bfWord;
bfWord myArray[(180/16)+1];

(You'll have to do 16 of 'em since ThC pads structs to even size.)
--
 Jamie McCarthy     Internet: [e-mail]     AppleLink: j.mccarthy
 "A common way to answer a question about C is to 'see what the compiler
  does.'  Clearly C has suffered from being partly defined, then
  implemented." - High C language reference manual, 1987










Path: ucivax!gateway
From: [e-mail] (Igor Livshits)
Subject: Re:  Array of bits?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 30
Date: 13 May 92 14:28:29 GMT

Thank you to all who responded to my query.  Apparently, the only way to do
it is through a bit test of a chunk of memory.  I probably do not want to
sacrifice the time delay in favor of memory savings.

Thanks again, igor



>Date: Wed, 13 May 92 08:29:11 EDT
>X-Ph: [e-mail]
>From: Brady Duga  <[e-mail]>
>To: [e-mail]
>Subject: Re:  Array of bits?
>
>How about :
>
>char inactive[NUMBER_O_FLAGS / 8];
>Then, to get flag x:
>
>div_t  d;
>
>d=div(x,8);
>if ( (inactive[d.quot] >> d.rem) & 0xFE) ...
>
>Of course, you could stick it all in a function, to make it look nicer.
>
>--Brady ([e-mail])
>
>











Path: ucivax!gateway
From: [e-mail] ("Bob (Mr. Grape loves ME!) Miller" )
Subject: Re: Array of bits?
Message-ID: <9205131904.AA27580@Mr_Grape.convex.com>
In-Reply-To: Your message of "13 May 92 14:28:29 GMT."
             <[e-mail]>
Newsgroups: fa.think-c
Lines: 24
Date: 13 May 92 19:05:31 GMT

Something like this would work.

#define DECLARE_BIT_ARRAY(name, size) char name[((size) + 7) / 8]
                    /* round up to next byte */
#define BIT_TEST(array, bitno) ((array[(bitno) >> 3] & \
                 1 << ((bitno) & 7)) != 0)
#define BIT_SET(array, bitno)   (array[(bitno) >> 3] |=   1 << ((bitno) & 7))
#define BIT_CLEAR(array, bitno) (array[(bitno) >> 3] &= ~(1 << ((bitno) & 7)))

Then, to use,

    DECLARE_BIT_ARRAY(inactive, 180);

    if (BIT_TEST(inactive, i))
        BIT_CLEAR(inactive, i);
    else if (!(jk_is_inactive = BIT_TEST(inactive, j + k)))
        BIT_SET(inactive, j + k);

How long does it take?  Each macro is probably four or five
instructions more than if you used an array of Booleans.

This sort of bitwise fumbling is what C really excels at.

                    K<bob>










Path: ucivax!gateway
From: [e-mail] (Eric Slosser)
Subject: HOORAY!!!!!!!"!!!
Message-ID: <[e-mail]>
In-Reply-To: Nathan Neulinger's message of 13 May 92 03:31:01 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 5
Date: 13 May 92 21:18:59 GMT


If printing is really slow, you may be able to speed things
by first imaging onto an appropriately sized offscreen port,
then CopyBitsing into the printing port.











Path: ucivax!gateway
From: osc![e-mail] (Vincent Tong)
Subject: Please remove me from the mailing list
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 2
Date: 14 May 92 00:23:31 GMT


Thanks










Path: ucivax!gateway
From: [e-mail] (Nick Nei)
Subject: How to Show Init with TC5.
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 18
Date: 14 May 92 14:27:01 GMT


I have an INIT written with TC4, using ShowINIT() given in LightSpeed C
(version 2.15).  It has a bit of assembler like so:

#define CKSM(i)                \
    asm {                    \
        ROL #1,i            \
        EOR #0x1021,i        \
    }

But when I compile it with TC5, it says "Syntax Error".  I am not an
assembler afficionado.  I have a feeling there is something better than
ShowINIT() now.  Can anyone help?

Mail:  Nick Nei, Computing Science Dept.,
       Glasgow Univ., 17 Lilybank Gardens,
       Glasgow G12 8QQ, UK.  Tel: [phone] x 5457
ARPA:  [e-mail] USENET: [e-mail]










Path: ucivax!gateway
From: [e-mail] (The sky is ecstasy dancing)
Subject: Linking problems...
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 22
Date: 15 May 92 00:45:19 GMT
X-Vmsmail-To: SMTP%"[e-mail]"

Hi,
  I am Mac programming learner, so I am using the book The Macintosh Progamming
Primer. (Great book by the way. :))  Anyways, I am doing  one of the programs
from the book (PritPICT), and when I try to link it, it tells me that all of the
Prxxx functions are undefined.

Normally I would say, "Ah ha!  I forgot to include the header file for
Printing!", but after examining my code I discovered that it was there.  I am
using Think C version 5.

I looked through the Think C manual wondering if I had installed TC wrong, but
everything appears to be in order.

Does anybody, have any ideas, cause I am clean out. :(

Mike

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Mike Ruhl
Operator
Arizona Cancer Center
[e-mail]










Path: ucivax!gateway
From: [e-mail] ("Bob (Mr. Grape loves ME!) Miller" )
Subject: '040 cache flush
Message-ID: <9205150321.AA17117@Mr_Grape.convex.com>
Newsgroups: fa.think-c
Organization: The GrapE-ics Lab
Lines: 4
Date: 15 May 92 03:22:14 GMT

Is there a Toolbox call to flush a 68040's cache after modifying
instructions?  I haven't been able to find one.

                    K<bob>










Path: ucivax!gateway
From: [e-mail] (Ephraim Vishniac)
Subject: Re: '040 cache flush
Message-ID: <[e-mail]>
In-Reply-To: Your message of "15 May 92 03:22:14 GMT."
             <9205150321.AA17117@Mr_Grape.convex.com>
Newsgroups: fa.think-c
Lines: 15
Date: 15 May 92 11:10:37 GMT


   Date:  15 May 92 03:22:14 GMT
   From:  "\"Bob (Mr. Grape loves ME!" <[e-mail]>, ")"@ics.uci.edu

   Is there a Toolbox call to flush a 68040's cache after modifying
   instructions?  I haven't been able to find one.

Look in the bottom of OSUtils.h:

pascal Boolean SwapInstructionCache(Boolean cacheEnable);
pascal void FlushInstructionCache(void);
pascal Boolean SwapDataCache(Boolean cacheEnable);
pascal void FlushDataCache(void);

Ephraim










Path: ucivax!gateway
From: [e-mail] (Michael Babin)
Subject: Linking problems...
Message-ID: <[e-mail]>
In-Reply-To: The sky is ecstasy dancing's message of 15 May 92 00:45:19 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 7
Date: 15 May 92 14:05:52 GMT


Did you add one of the ANSI libraries (ANSI, ANSI-small, etc.) to your
project?  If not, then the linker can't find the object code for those
functions.

Mike Babin
[e-mail]










Path: ucivax!gateway
From: [e-mail] (The sky is ecstasy dancing)
Subject: Summary... :)
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 18
Date: 15 May 92 16:21:54 GMT
X-Vmsmail-To: SMTP%"[e-mail]"

Hi again!

   Last night I went home and discovered that there is more to the Think C
manual than the Appendixes, and so I discovered what I was doing wrong.  In
order to use the header Printing.h, I would have needed to Add PrGlue as well.
This apperently is the "old" way of printing, and does not use the print
manager.  The "new" way is to use PrintTraps.h.  This has all of things needed
for backgroung printing with the print manger.  MacTraps2 was not needed.

Thanks for all of your answers. :)

Mike

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Mike Ruhl
Operator/beginning Mac Programmer
Arizona Cancer Center
[e-mail]










Path: ucivax!gateway
From: [e-mail] (Nick Nei)
Subject: DES source code anyone?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 11
Date: 16 May 92 01:55:41 GMT


Does anyone know of any PD available or willing to donate DES encryption
source code?  Either C or Pascal, but C preferred.  Either MPW or THINK,
but THINK preferred.

Thanks in salivating anticipation...

Mail:  Nick Nei, Computing Science Dept.,
       Glasgow Univ., 17 Lilybank Gardens,
       Glasgow G12 8QQ, UK.  Tel: [phone] x 5457
ARPA:  [e-mail] USENET: [e-mail]










Path: ucivax!gateway
From: [e-mail] (Harry Morris)
Subject: DES source code anyone?
Message-ID: <[e-mail]>
In-Reply-To: Nick Nei's message of 16 May 92 01:55:41 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 20
Date: 16 May 92 02:57:13 GMT


um, I may be wrong, but I'm pretty sure it's illegal to export DES out of
the United States.



   From: Nick Nei <[e-mail]>
   Date: 16 May 92 01:55:41 GMT


   Does anyone know of any PD available or willing to donate DES encryption
   source code?  Either C or Pascal, but C preferred.  Either MPW or THINK,
   but THINK preferred.

   Thanks in salivating anticipation...

   Mail:  Nick Nei, Computing Science Dept.,
      Glasgow Univ., 17 Lilybank Gardens,
      Glasgow G12 8QQ, UK.  Tel: [phone] x 5457
   ARPA:  [e-mail] USENET: [e-mail]










Path: ucivax!gateway
From: [e-mail] (Juri Munkki)
Subject: DES restrictions
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 8
Date: 16 May 92 06:59:02 GMT

US regulations can not affect non-US implementations of DES. One of the
guys who works here at the computing centre has his own implementation
of DES (a very high quality one too) and he has written a Macintosh version
of it too (in Think C).

I forwarded Nick's message to the author.

    Juri










Path: ucivax!gateway
From: [e-mail]
Subject: Re: Linking problems...
Message-ID: <9205161106.AA00211@spinner>
In-Reply-To: Your message of 15 May 92 00:45:19 +0000.
             <[e-mail]>
Newsgroups: fa.think-c
Lines: 23
Date: 16 May 92 11:07:06 GMT

Your message dated: 15 May 92 00:45:19 GMT

>Hi,
>  I am Mac programming learner, so I am using the book The Macintosh Progamming
>Primer. (Great book by the way. :))  Anyways, I am doing  one of the programs
>from the book (PritPICT), and when I try to link it, it tells me that all of the
>Prxxx functions are undefined.

>Normally I would say, "Ah ha!  I forgot to include the header file for
>Printing!", but after examining my code I discovered that it was there.  Iam
>using Think C version 5.

A Ha!  The header file includes information that is used at _compile_ time.
If this was the problem you would find out then.  (Or, depending on your
compiler settings, you'd just get weird things happening at run time.)

However, since it's a _linker_ error, you're missing a library.  If I remember
right (I'm not sure), there's one called PrTraps or something like that.
Use the Add... command to add it to your project.

Good luck,

--Paul Franklin ([e-mail])










Path: ucivax!gateway
From: [e-mail]
Subject: Animation Problem
Message-ID: <01GK267Q1HLS8ZE3FL@TAYLORU>
Newsgroups: fa.think-c
X-VMS-To: IN%"[e-mail]"
Lines: 157
Date: 16 May 92 12:43:11 GMT
X-Envelope-to: [e-mail]

This program is my attempt to learn how to program smooth animation, but I am
having a very strange problem.  The program works fine except that the object
disapears when the object is above line 120 on the screen.  If anyone can help
me with this problem, please email me.

Mark Goddard
[e-mail]
[e-mail]

Here is the code, the CreateOffScreenBitmap was an example in Think Reference:


#include <Palettes.h>
#include <Retrace.h>
#define INTERVAL 1
#include <Events.h>
#include <Quickdraw.h>
#include <Windows.h>
#include <QDOffScreen.h>
#define kIsVisible TRUE
#define kNoGoAway FALSE
#define kNoWindowStorage 0L
#define kFrontWindow ((WindowPtr) -1L)

typedef struct MyTaskElem {
long myA5; /* 4 bytes before the  VBLTask  data */
VBLTask myTask;
} MyTaskElem;

MyTaskElem taskElem; /* allocate the 18-byte structure */
WindowPtr       wind;
PicHandle thePic,backGround,theMask;
Rect  drawRect,saveRect,sourceRect;
int dh=1,dv=1;
GrafPtr maskbit;
RgnHandle mask;
GWorldPtr saveBuffer;
GDHandle windDevice;
QDErr err;

void doMyVBL(); /* predefine the function */
Boolean CreateOffscreenBitMap(GrafPtr *, Rect *);
void DestroyOffcreenBitMap(GrafPtr);


main()
{
        InitGraf(&thePort);
        InitWindows();

        thePic = GetPicture (300);
        theMask = GetPicture (400);
        backGround = GetPicture (501);
        wind = GetNewCWindow (128, nil, (WindowPtr) -1);
        err = NewGWorld(&saveBuffer, 0, &(wind->portRect), nil, nil, noNewDevice
   );
        SetPort(wind);
        GetGWorld(&wind,&windDevice);
        SetGWorld(wind,windDevice);
        DrawPicture(backGround,&((*backGround)->picFrame));
        sourceRect = ((*thePic)->picFrame);
        SetGWorld(saveBuffer,nil);
        LockPixels(GetGWorldPixMap(saveBuffer));
        DrawPicture(thePic,&sourceRect);
        UnlockPixels(GetGWorldPixMap(saveBuffer));
        if (CreateOffscreenBitMap(&maskbit,&((*theMask)->picFrame))) {
                SetPort(maskbit);
                DrawPicture(theMask,&(*theMask)->picFrame );
                }
        else ExitToShell();
        SetPort(wind);
        drawRect = (*thePic)->picFrame;
        saveRect = (*thePic)->picFrame;
        OffsetRect(&drawRect,0,0);
        OffsetRect(&saveRect,0,50);
        LockPixels(GetGWorldPixMap(saveBuffer));
        CopyBits(&wind->portBits,*(GetGWorldPixMap(saveBuffer)),&drawRect,&saveR
   ect,srcCopy,0L);

        taskElem.myTask.qType =  vType ;
        taskElem.myTask.vblAddr = doMyVBL; /* address of a task */
        taskElem.myTask.vblCount = INTERVAL; /* Set the interval */
        taskElem.myTask.vblPhase = 0;
        taskElem.myA5 = (long) CurrentA5 ; /* save app's A5 in structure*/
        if (SlotVInstall(&taskElem.myTask,0)!= 0)
                SysBeep(10);
        while (!Button());
        UnlockPixels(GetGWorldPixMap(saveBuffer));
        DestroyOffcreenBitMap(maskbit);
        SlotVRemove (&taskElem.myTask,0); /* remove your task later */
}


/* ============= the VBL task code itself  =============*/
void doMyVBL()
{
GrafPtr savePort;
asm { move.l A5, -(SP) /* save current value of A5 */
move.l -4(A0), A5 } /* read app A5 from structure */
if ((drawRect.right > 400) || (drawRect.left < 0)) dh *= -1;
if ((drawRect.bottom > 400) || (drawRect.top < 0)) dv *= -1;
CopyBits(*(GetGWorldPixMap(saveBuffer)),&wind->portBits,&saveRect,&drawRect,srcC
   opy,0L);
OffsetRect(&drawRect,dh,dv);
CopyBits(&wind->portBits,*(GetGWorldPixMap(saveBuffer)),&drawRect,&saveRect,srcC
   opy,0L);
CopyMask (*(GetGWorldPixMap(saveBuffer)),&maskbit->portBits, &wind->portBits, &s
   ourceRect, &(maskbit->portRect),&drawRect);
taskElem.myTask.vblCount = INTERVAL;  /* Reset for next interval */
asm { move.l  (SP)+, A5 } /* restore value of A5 */
}

Boolean CreateOffscreenBitMap(GrafPtr *newOffscreen, Rect *inBounds)
{
        GrafPtr savePort;
        GrafPtr newPort;
        GetPort(&savePort); /* need this to restore thePort after OpenPort */
        newPort = (GrafPtr)NewPtr(sizeof(GrafPort));  /* allocate the grafPort *
   /
        if(MemError() != noErr)
                return FALSE;
        OpenPort(newPort);
        /* make bitmap the size of the bounds that caller supplied */
        newPort->portRect = *inBounds;
        newPort->portBits.bounds = *inBounds;
        RectRgn(newPort->clipRgn, inBounds);
        RectRgn(newPort->visRgn, inBounds);
        /* rowBytes is size of row, must be rounded up to an even number of byte
   s */
        newPort->portBits.rowBytes =
        ((inBounds->right - inBounds->left + 15) >> 4) << 1;
        /* number of bytes in BitMap is rowBytes * number of rows */
        /* see notes at end of example about using NewPtr instead of NewHandle *
   /
        newPort->portBits.baseAddr =
        NewPtr(newPort->portBits.rowBytes * ( long )(inBounds->bottom -
        inBounds->top));
        if(MemError() != noErr)
        {
                SetPort(savePort);
                ClosePort(newPort); /* dump the visRgn and clipRgn */
                DisposPtr((Ptr)newPort); /* dump the GrafPort */
                return FALSE; /* tell caller we failed */
        }
        /* since the bits are just memory, let's clear them before we start */
        EraseRect(inBounds);/* OpenPort did a SetPort(newPort) so we are OK*/
        *newOffscreen = newPort;
        SetPort(savePort);
        return TRUE; /* success */
}

void DestroyOffcreenBitMap(GrafPtr oldOffscreen)
{
        ClosePort(oldOffscreen); /* dump the visRgn and clipRgn */
        DisposPtr(oldOffscreen->portBits.baseAddr); /* dump the bits */
        DisposPtr((Ptr)oldOffscreen); /* dump the port */
}










Path: ucivax!gateway
From: [e-mail] (Bob Miller)
Subject: Re:  Animation Problem
Message-ID: <9205161406.AA24298@Mr_Grape.convex.com>
Newsgroups: fa.think-c
Lines: 24
Date: 16 May 92 14:07:22 GMT

> This program is my attempt to learn how to program smooth animation, but I am
> having a very strange problem.  The program works fine except that the object
> disapears when the object is above line 120 on the screen.  If anyone can help
> me with this problem, please email me.

The problem is that it takes your program nonzero time to save part of
the background.  It takes about as long as it takes the video hardware to
refresh the first 120 screen lines.

I suggest you use TWO offscreen bitmaps.  Build the composite image
in the second bitmap, then copy from it to the screen.  Save and
restore the saverect in the second bitmap, but never save/restore
anything on the screen.

That way, there's always a copy of the foreground picture on the
screen.  While lines above 120 are being refreshed, it's the
picture from the previous frame instead of the current one,
but in most cases that isn't too objectionable.

As a general rule, it doesn't work to use the screen to store bitmaps.
What if part of the window is obscured by another window?
Then the pixels "behind" that window would be gone forever.

                    K<bob>










Path: ucivax!gateway
From: [e-mail] (Kent Sandvik)
Subject: Re: Re- '040 cache flush
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 9
Date: 16 May 92 22:35:09 GMT

                           RE>Re: '040 cache flush
Tech Note 261 is a useful one concerning caching issues and coding.

Cheers,
Kent/DTS


      Caffeine











Path: ucivax!gateway
From: [e-mail] (Kirk Swenson)
Subject: Re: Animation Problem
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 29
Date: 17 May 92 17:12:10 GMT


> This program is my attempt to learn how to program smooth animation, but I am
> having a very strange problem.  The program works fine except that the object
> disapears when the object is above line 120 on the screen.

As Bob Miller points out, the problem is that the first two CopyBits
to restore and save the background take time.  By the time the code is
drawing the object, the beam has already passed line 120.  There is
another potential problem in the code provided, however.

>void doMyVBL()
>{
...
>CopyBits(*(GetGWorldPixMap(saveBuffer)),&wind->portBits,&saveRect,&drawRect,srcCopy,0L);
OffsetRect(&drawRect,dh,dv);
>CopyBits(&wind->portBits,*(GetGWorldPixMap(saveBuffer)),&drawRect,&saveRect,srcCopy,0L);
>CopyMask (*(GetGWorldPixMap(saveBuffer)),&maskbit->portBits, &wind->portBits, &sourceRect, &(maskbit->portRect),&drawRect);
...
>}

CopyBits and CopyMask are both routines that may make Memory Manager
calls, therefore they cannot safely be called at interrupt time.  Your
VBL routine should set a global flag, which your application can then
poll to determine when it is time to draw.

Kirk Swenson
UC Berkeley
[e-mail]











Path: ucivax!gateway
From: [e-mail] (The sky is ecstasy dancing)
Subject: Re: Linking problems...
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 13
Date: 19 May 92 13:18:59 GMT
X-Vmsmail-To: SMTP%"[e-mail]"

The file needed would be PrGlue. :)  I also found that if I want to use the
print manager, I should include PrintTraps.h instead of Printing.h and PrGlue.

Thanks for the input.

Mike.

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Mike Ruhl
Operator/Mac learner
Arizona Cancer Center
[e-mail]











Path: ucivax!gateway
From: [e-mail] (David Sugar)
Subject: Hmm..
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 11
Date: 21 May 92 00:21:18 GMT


  I havn't noticed much activity on this mailing list recently.  It seems
that once the tcl list formed many people have moved over there.  But, I
have a quesiton, unfortunilty it isn't a C question.  I just need to
know at what address I can mail Symantec because I have a possible bug
to report in Think Pascal..

  Dave Sugar

  [e-mail]











Path: ucivax!gateway
From: [e-mail] (MIKOLIC-TORREI I)
Subject: Address for Symantec
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 22
Date: 21 May 92 03:20:43 GMT


Dave,

Symantec's address is:

Symantec Corporation
10201 Torre Avenue
Cupertino, CA 95014

[phone]

Might I suggest that the best place for a bug report is the Symantec
area on CompuServe.  I've always had _excellent_ response when I posted
specific issues/questions there.  The only draw back is the $$$$.

I've also noticed that this list is a bit quiet lately--I doubt it's because
people moved to the TCL list.  I suscribe to both and that one's pretty
quiet recently too (although not quite as quiet as this one).

Igor Mikolic-Torreira
[e-mail]











Path: ucivax!gateway
From: [e-mail] (King Rhoton)
Subject: Symantec
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 4
Date: 21 May 92 12:38:06 GMT

You can also leave bug reports/messages to Symantec on their BBS (if you don't
have access to Compuserve).  For 2400 baud, call [phone].  For 9600
and higher, call [phone].
King










Path: ucivax!gateway
From: [e-mail] (King Rhoton)
Subject: MapRect
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 6
Date: 21 May 92 12:42:20 GMT

So, does anyone out there have any ideas about why I'm having the following
problem?  Specifically, I'm trying to resize a 320x240 graphic into a
window for display.  For window sizes up to 160x120, everything works fine.
However, for any window size large, all I get is the upper left area of the
full-size graphic.  Any ideas would be appreciated.
King










Path: ucivax!gateway
From: [e-mail]
Subject: (none)
Message-ID: <01GK9LGCWT688ZEBHH@TAYLORU>
Newsgroups: fa.think-c
X-VMS-To: IN%"[e-mail]",IN%"[e-mail]"
Lines: 1
Date: 21 May 92 13:08:38 GMT
X-Envelope-to: [e-mail]

Please remove me from this list.










Path: ucivax!gateway
From: [e-mail] (Phil Shapiro)
Subject: Hmm..
Message-ID: <[e-mail]>
In-Reply-To: David Sugar's message of 21 May 92 00:21:18 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 16
Date: 21 May 92 13:10:25 GMT

>>>>> On 21 May 92 00:21:18 GMT, David Sugar <[e-mail]> said:

 > I just need to know at what address I can mail Symantec because I
 > have a possible bug to report in Think Pascal..

You can (and should) email bugs regarding THINK C and THINK Pascal to
either [e-mail], or [e-mail]. Our
Tech Support staff makes it a point to reply to messages that are
gatewayed from the Internet to AppleLink and CIS, since we (at
present) do not have a direct Internet connection.

    -phil
----
   Phil Shapiro                                   Software Engineer
   Language Products Group                     Symantec Corporation
           Internet: [e-mail]










Path: ucivax!gateway
From: [e-mail] (Phil Shapiro)
Subject: Address for Symantec
Message-ID: <[e-mail]>
In-Reply-To: MIKOLIC-TORREI I's message of 21 May 92 03:20:43 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 27
Date: 21 May 92 13:13:35 GMT

>>>>> On 21 May 92 03:20:43 GMT, MIKOLIC-TORREI I <[e-mail]> said:
 > Symantec's address is:

 > Symantec Corporation
 > 10201 Torre Avenue
 > Cupertino, CA 95014

 > [phone]

This is the address and phone number for Symantec's main office. To
reach the THINK Tech Support gurus, you should use this address
instead:

Symantec Corp
135 South Road
Bedford, MA 01730

[phone] (voice)
[phone] (FAX)

If you FAX, keep the source listing down to a page or two of code.

    -phil
----
   Phil Shapiro                                   Software Engineer
   Language Products Group                     Symantec Corporation
           Internet: [e-mail]










Path: ucivax!gateway
From: [e-mail] (Rex Bontrager)
Subject: Re: Address for Symantec
Message-ID: <[e-mail]>
In-Reply-To: Your message of 21 May 92 03:20:43 GMT
Newsgroups: fa.think-c
Lines: 16
Date: 21 May 92 15:48:32 GMT

On 21 May 92 03:20:43 GMT you said:
>Might I suggest that the best place for a bug report is the Symantec
>area on CompuServe.  I've always had _excellent_ response when I posted
>specific issues/questions there.  The only draw back is the $$$$.

Do you know Symantec's Compuserve id; i.e., of the form nnnnn,nnnn?
Internet and Bitnet people can correspond with Compuserve accounts if
we know the numeric id.


Rex Bontrager
IBM Systems Programmer, IBM Postmaster
Purdue University Computing Center
Bitnet:    rexb@purccvm
Internet:  [e-mail]
Phone:     [phone] ext. 256










Path: ucivax!gateway
From: [e-mail] (TJ Leone)
Subject: Apple Event Object Support Library
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 10
Date: 21 May 92 15:48:39 GMT

Is there a THINK C version of the Apple Event Support Library available via ftp?  apda
Developer's CD?  anyplace else?

Thanks,

TJ Leone, Research Associate
Biomedical Information Communication Center
Oregon Health Sciences University

[e-mail]










Path: ucivax!gateway
From: [e-mail] (Ed Rush)
Subject: Re:  Address for Symantec
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 12
Date: 21 May 92 16:46:15 GMT

>Might I suggest that the best place for a bug report is the Symantec
>area on CompuServe.

Don't forget that Symantec also runs its own BBS. The telephone
number is in the manual (which I do not have handy right now).
  -----------------------------------------
  Ed Rush, employed by but not speaking for
  Metaphor Computers, Mtn. View, CA
     UUCP: [...!{apple|decwrl}!]metaphor!rush
     Internet: [e-mail]
  -----------------------------------------
Calm down, everyone, it's only ones and zeroes.










Path: ucivax!gateway
From: [e-mail]
Subject: List
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 3
Date: 21 May 92 18:25:10 GMT

Please remove me from the list.
Peter Gerhardstein ([e-mail])











Path: ucivax!gateway
From: [e-mail] (Nathaniel Titterton)
Subject: making MPW format object files...
Message-ID: <[e-mail]>
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: fa.think-c
Lines: 16
Date: 21 May 92 22:35:44 GMT


I am using MCL2.0 (Macintosh Common Lisp) and want to use its
foreign function capabilities.  However, it requires an object
file in MPW format, which of course, think-c can't really make.
In talking to Symantec, they said that I could use ThinkPascal
as an intermediary, having it read in a think-c library and then
write out a MPW compatable library (which it automatically does).
   Well, I haven't got this to work...  Does anyone have any
experience with this?  Is that fact that I am using Pascal 3.0
to blame (Symantec says probably not).  What other libraries
should I include in the pascal library, if any (it automagically
puts some there...)?  Sheesh.

Thanks a lot for any help...

-nate










Path: ucivax!gateway
From: [e-mail] (Rich Siegel)
Subject: Re:  making MPW format object files...
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 9
Date: 22 May 92 00:36:13 GMT

It's probably not necessary to add any of THINK Pascal's own libraries
to the project to build your .O file, unless some of the code is in
Pascal. Otherwise, there's no reason you can't use THINK Pascal as
a mechanism for translating THINK C libraries into .O files.

Since you didn't give any specific information on why it doesn't
work, it's pretty difficult to offer useful assistance.

R.










Path: ucivax!gateway
From: [e-mail]
Subject: please remove me from the list
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
X-VMS-To: IN%"[e-mail]"
Lines: 1
Date: 22 May 92 01:27:17 GMT
X-Envelope-to: [e-mail]

please remove me from the list.  bye










Path: ucivax!gateway
From: [e-mail] (Rich Siegel)
Subject: Re:  making MPW format object files...
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 7
Date: 22 May 92 01:49:56 GMT

After using DumpObj to dump the .O file, it becomes clear that THINK Pascal
uppercases the entry-point name, so try using 'DEFFCFUN' instead, if MCL
is case-sensitive (which it probably is, in this case).

This is reasonable behavior, because names are case-insensitive in Pascal.

R.










Path: ucivax!gateway
From: [e-mail] (Hong Zhou)
Subject: sign off
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 1
Date: 22 May 92 07:58:32 GMT

unsubscribe think-c










Path: ucivax!gateway
From: osc![e-mail] (Vincent Tong)
Subject: please remove me from the list
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 6
Date: 22 May 92 18:08:38 GMT


please remove me from the list

Thanks

Vincent










Path: ucivax!gateway
From: [e-mail] (Gary Letourneau)
Subject: remove me from think-c list
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 3
Date: 22 May 92 18:47:09 GMT


unsubscribe think-c











Path: ucivax!gateway
From: [e-mail] (Richard Wolf 6-4527)
Subject: Everyone who's thinking about unsubscribing and sending E-mail
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 18
Date: 22 May 92 20:02:43 GMT

          to [e-mail] ...

The following is for those of you who are thinking about unsubscribing
to this list and sending your request to [e-mail].

Don't !!  If I see another piece of E-mail on this list asking that
someone be unsubscribed, I think I'm gonna go nuts!

Send your reguests ... drum roll please ... to ...

     [e-mail]

How you can get as far as programming the Mac in C and yet not be able to
follow this simple rule really amazes me.  After all, it's not as though
this list were somehow the exception to the general rule.  When you
subscribed to this list, you were sent instructions on how to do take
care of official requests, such as unsubscribing.











Path: ucivax!gateway
From: [e-mail] (Ed Rush)
Subject: How to leave the think-c list
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 7
Date: 22 May 92 21:13:20 GMT

Mailboxes everywhere are being cluttered with people trying to
leave the Think C mailing list.  PLEASE, if you want to
unsubscribe, send the word to:

[e-mail]

DO NOT send it to the list at large.










Path: ucivax!gateway
From: [e-mail] ("Jeffrey S. Pace")
Subject: please remove me ...
Message-ID: <[e-mail]>
X-Mailer: ELM [version 2.2 PL16]
Newsgroups: fa.think-c
Lines: 13
Date: 23 May 92 02:34:35 GMT


Please remove me from your list.

--

                         /////////////////////////
 ///////////////////////+-----------------------+/
+-----------------------+ BRS Software Products |///////////////////////////////
|    Jeffrey S. Pace    |     1200 Route 7    +-----------------------------+/
+-----------------------+   Latham, N.Y. 12110  | ARPA: [e-mail] |/
            +-----------------------+                  |/
   Hey Moe ...                |  UUCP: uunet!crdgw1!brspyr1!jeffp   |/
    -Curly Howard            +-------------------------------------+










Path: ucivax!gateway
From: [e-mail] (geoff george)
Subject: Think C 5.0.2 vs. TMON Pro 3.0
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 20
Date: 23 May 92 05:18:05 GMT

The TC5 docs say (p. 245) that TMON's V variable will be set to the value
of the application's program counter when TMON (2.8.x) is invoked from
the TC debugger via the Monitor command. This doesn't appear to work for
TMON Pro 3.0, using TC 5.0.2. Am I missing something?

What I want to do is turn on Discipline inside TMON, then step through
my code with the TC debugger waiting for Discipline to invoke TMON, to
effectively get Discipline to interact with the TC debugger. Is there
a better way to do this? Is there a later TMON or TC debugger?


geoff
5/23/92

--
geoff george    [e-mail]        (my name)
        or    [e-mail]   (personal warmth from GaTech OCS)

"Ordinary f---ing people - I hate 'em. Ordinary person spends his life avoiding
tense situations; repo man spends his life getting INTO tense situations."










Path: ucivax!gateway
From: [e-mail]
Subject: Re: please remove me ...
Message-ID: <[e-mail]>
In-reply-to: Your message of 23 May 92 02:34:35 +0000.
             <[e-mail]>
Newsgroups: fa.think-c
Lines: 4
Date: 23 May 92 05:21:58 GMT

Perhaps everyone on the list should reply to this type of message
and people will start using "request"?  1/2 :-)

Ian










Path: ucivax!gateway
From: [e-mail] (geoff george)
Subject: Think C 5.0.2 vs. TMON Pro 3.0 reprise
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 21
Date: 23 May 92 19:41:45 GMT

If I drop from the TC debugger into TMON via the Monitor command, how
can I find out the current value of my application's PC?

Also, why does the TC debugger report different addresses for functions
than does TMON? For example (I just checked) "& main" is reported by
the TC debugger to be 0x25BCE2 when TMON says it's $0019986A. When the
TC debugger reports that an error happened at some address, does it give
the correct address?

I'm running system 7.0 with the Tune-Up 1.1.1, on a Mac II with 5MB,
with Mode32 disabled.

geoff
5/23/92

--
geoff george    [e-mail]        (my name)
        or    [e-mail]   (personal warmth from GaTech OCS)

"Ordinary f---ing people - I hate 'em. Ordinary person spends his life avoiding
tense situations; repo man spends his life getting INTO tense situations."










Path: ucivax!gateway
From: [e-mail] (Phil Shapiro)
Subject: Think C 5.0.2 vs. TMON Pro 3.0 reprise
Message-ID: <[e-mail]>
In-Reply-To: geoff george's message of 23 May 92 19:41:45 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 40
Date: 24 May 92 15:14:23 GMT

>>>>> On 23 May 92 19:41:45 GMT, geoff george <[e-mail]> said:

 > If I drop from the TC debugger into TMON via the Monitor command,
 > how can I find out the current value of my application's PC?

You'll have the use the technique described in the "other debuggers"
section -- the current PC is located at (PC-4)^. You can probably
write a macro for TMON Pro to simplify this.

 > Also, why does the TC debugger report different addresses for
 > functions than does TMON? For example (I just checked) "& main" is
 > reported by the TC debugger to be 0x25BCE2 when TMON says it's
 > $0019986A. When the TC debugger reports that an error happened at
 > some address, does it give the correct address?

This is actually a pretty interesting problem. The answer is that it's
because the expressions in the data window are evaluated as if they
appear in the code stream in your program. There isn't any expression
evaluator; the compiler itself is used to generate code for data
window expressions.

So, if you take the address of a function, you get the same result as
if you took its address in you program; you get its jump table entry.
There's actually a bug in the debugger where if you try and display
the address of a static function, you'll get a fake jump table entry.
PC-relative addresses for static functions aren't generated by the
compiler, but by the linker.

Given that you have the address of the jump table entry, and given
that it's a loaded entry, you can probaby use an expression like:

    *(Ptr *)((char *)&main + 4) // should return "real" address of main

(off the top of my head, no guarantees)

    -phil
----
   Phil Shapiro                                   Software Engineer
   Language Products Group                     Symantec Corporation
           Internet: [e-mail]










Path: ucivax!gateway
From: [e-mail] (Igor Livshits)
Subject: Screwy menu hook
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 26
Date: 24 May 92 18:16:22 GMT

Hello,

I am having some problems with the menu hook to accommodate the extra width
of the down arrow in a popup menu.  I have a dialog with a list box where
one may add elements.  Each element has its own popup menu that I swap in
and out of the same pane as an item is selected.  This works great as long
as I have only one (CBartender has to load and add the menu) of each
elements (therefore, every menu is used just once).

This breaks down once a second instance of the same element is added
(CBartender already has the menu).  Now, two separate objects are trying to
share the same menu handle.  The hook screws up the menu width and
itsMenu->GetWidth() returns -1.

Once I close and dispose of the dialog and invoke a brand new one
(CBartender already has the menu), all menus will work fine, but everything
is as though the hook never existed!

Any suggestions?  I will send source code if anyone would like to take a
look at it.

Everything is dandy if I never bother with the hook.


Thanks, Igor











Path: ucivax!gateway
From: [e-mail]
Subject: Mixing Pascal and C
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 12
Date: 25 May 92 04:29:58 GMT
X-Vmsmail-To: EMAIL"[e-mail]"

I'm having a problem mixing Pascal and C. Why would anyone want to? Well..

I need to add some routines (written in think C) to an application written in
Think Pascal. So I wrote the routines in think C saved them as a library
and loaded them into the pascal project. No problems. Until I needed to use
the c library routines. I either get messages that the routines are not
defined at link time in pascal. OR multiply defined if  I include the
libraries into think c before saving as a library. Any suggestions on how
this should be handled.

Ralph Pugmire, Massey University, New Zealand.
[e-mail]










Path: ucivax!gateway
From: [e-mail] (Bruce Johnson)
Subject: Removal from list
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 5
Date: 25 May 92 05:33:35 GMT


Please remove my name from the think-c mailing list

Bruce Johnson
[e-mail]










Path: ucivax!gateway
From: [e-mail] (Jean-Marie Laborde)
Subject: Strange Bug?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 59
Date: 25 May 92 16:07:46 GMT

Rewriting the code for removing unwanted resources for the program Cabri-geometre, I encoutered the following strange bug:
(The code has been made as small as possible)

/*************************************/
#include <MacHeaders>
#include <stdlib.h>
#include <stdio.h>

int       pathRefNum,
          sauve_pathRefNum,
       number;
char   essai[8]="1 2 3 4",
          *carPtr=&essai[0];

void main(void)
{
/* standard initilizations: */
           InitGraf(&thePort);
        InitWindows();
           InitMenus();
           InitFonts();
           InitDialogs(0L);
           InitCursor();
           TEInit();

           OpenResFile("\pApplic");

// the bug:
    number=atoi(carPtr);
           printf("val= %d \n",number);
           while (!Button());
}
/*************************************/

Librairies are ANSI and MacTraps.
It must exist a file named "Applic" at the same level as the project.
There no BUG when the cooresponding code is build in an Application.

There is a bug (the Mac freeze very severely) under Think_C5 with or without the Debugger option.
The BUG is at least on a Qudra 900, a Ci, a IIfx  or a SE30 (freezes less severely).

The BUG does not occur if you call atoi() a first time before OpenResFile().
The BUG does not occur if you have a file "Applic" with no Code ressource, but
        it comes when certain Code ressource are present, as in an appliction
        mostly empty build using the simplest possible code      main(){}
        and ThinkC5.
        This gives an apllication with 3 CODE resources. You should
        then duplicate the CODE having ID 2 (6 bytes long) and give it the ID 5.
        (It seems it's important that there is a code with ID 5 to provoque the
        BUG)

The BUG does not occur when using ThinkC4.0 (IIfx) and adapting the code
        accordingly.

I use System 7.01 (US and France) and I dont know the situation under System 6.x.

Thank you for helping.












Path: ucivax!gateway
From: [e-mail] (Rich Siegel)
Subject: 'unsubscribe' noise
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 17
Date: 25 May 92 17:36:52 GMT


It seems that many people know to mail to think-c-request to subscribe,
but to unsubscribe, they always seem to mail to think-c, with the results
we all know about.

The course of action I suggest is this: if an unsubscribe request goes out
to the general list, it will not be acted upon, and the readers of the list
(or some subset thereof) will send a message to the originator advising him
that administrative requests should go to think-c-request, not to think-c.
This has two benefits: novices reading the list (and considering unsubscribing)
will be repeatedly reminded of the correct mechanism, and the person who
asked to unsubscribe will (hopefully) get the message and use the correct
mechanism.

Feedback and refinements are welcome.

R.










Path: ucivax!gateway
From: [e-mail] (Phil Shapiro)
Subject: Mixing Pascal and C
Message-ID: <[e-mail]>
In-Reply-To: [e-mail]'s message of 25 May 92 04:29:58 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 24
Date: 25 May 92 17:49:25 GMT

>>>>> On 25 May 92 04:29:58 GMT, [e-mail] said:

 > I need to add some routines (written in think C) to an application
 > written in Think Pascal. So I wrote the routines in think C saved
 > them as a library and loaded them into the pascal project. No
 > problems. Until I needed to use the c library routines. I either
 > get messages that the routines are not defined at link time in
 > pascal. OR multiply defined if I include the libraries into think c
 > before saving as a library. Any suggestions on how this should be
 > handled.

The best solution is to rewrite the THINK C code so that is no longer
relies on the ANSI library routines. This may or may not be easy, but
it's a lot easier than getting the ANSI library itself to work inside
of THINK Pascal. If you need routines like printf() or sprintf(), you
may be better off writing specific routines in Pascal (eg,
print_string(), or format_float()), and then calling them from the C
code.

    -phil
----
   Phil Shapiro                                   Software Engineer
   Language Products Group                     Symantec Corporation
           Internet: [e-mail]










Path: ucivax!gateway
From: [e-mail]
Subject: Where is  fopenw()
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 39
Date: 25 May 92 17:50:15 GMT
X-Envelope-to: [e-mail]



Hello all,

Since some time I am doing some bug-fixing on NET/Mac, a program for HAM-radio
stations. The sources are Think C 3.0X sources, and therefor (I think) the
resulting application is not 32 bit clean... Now I figured out, that probably
the first step to take was 'migrating' the sources to Think C 4.0X, and doing
so, I discovered that fopenw(), which was available in 3.0X is no longer
available in 4.0X.

This means I will have to do a lot of programming in order to get the Think 4
version to work, since fopenw() is heavily used.

Can anybody tell me if there is some kind of an interface between the old
fopenw() call and the newer compiler? If not, some hints maybe?

Please help me out, I'm stuck...

Regards,
  __
 /_/  _/  _   ___
/ / (_/ (_/ / / /

(Adam van Gaalen)        phone: (31) 15 - 697283

+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -+
| Please send your reply to:                 |Goes to |Mac  |Software  |
+ - - - - - - - - - - - - - - - - - - - - - -+- - - - + - - + - - - - -+
|   internet:[e-mail]                 | office |LC   |NCSATelnet|
|         or:[e-mail]               |  same  |same |   same   |
|earn/bitnet:[e-mail]          |  same  |same |   same   |
|  Ham-radio:pa2aga@pa2aga   (44.137.32.9)   |my place|IIx  | NET/Mac  |
|         or:pa2aga@pa2aga-1 (44.137.32.61)  |  same  |512Ke|   same   |
|         or:pa2aga@pa2aga-2 (44.137.32.19)  |  same  |512Ke|   same   |
|         or:pa2aga@pa2aga-10(44.137.32.104) |  same  |PB100|   same   |
|         or:pa2aga@pi8mac   (44.137.32.22)  |  same  |SE/30|   same   |
|    Ham BBS:[e-mail]            |  same  |any/5|   same   |
+ - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -+










Path: ucivax!gateway
From: [e-mail] (Phil Shapiro)
Subject: Strange Bug? - segment loader problem
Message-ID: <[e-mail]>
In-Reply-To: Jean-Marie Laborde's message of 25 May 92 16:07:46 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 23
Date: 25 May 92 19:47:20 GMT

You're having a problem with the way that the segment loader works.
The call to atoi() causes the segment that contains the ANSI code to
be loaded in using the segment loader. Since your code opens up a
resource file that contains a CODE resource with the same resource ID
as the one the loader's looking for, it loads the file's CODE resource
instead. This causes the crash that you're getting, since the file's
CODE resource is completely different than the one in your
application.

It doesn't occur if you call atoi() first since the segment loading
has already occurred; the ANSI code segment has already been loaded,
and its jump table entry is already loaded.

I would avoid opening resource files that can contain CODE segments
(or any other resources that may conflict with your app's). If you
need to open files like this, then you'll have to use UseResFile() to
swap between your app's resource fork and the subfiles resource forks.

    -phil
----
   Phil Shapiro                                   Software Engineer
   Language Products Group                     Symantec Corporation
           Internet: [e-mail]










Path: ucivax!gateway
From: [e-mail] (Bill Hofmann)
Subject: Bug, or not?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 15
Date: 26 May 92 16:19:38 GMT

In previous versions of THINK, and I believe in current versions of MPW C, this
line produces a syntax error ("Can't take address of inline function"):

    MoreMasters;

THINK 5.x doesn't, it just ignores it.  This is a significant problem for my
students, who seem always to forget that Pascal omits parens when there's no
arguments, but C doesn't.  I'd argue that it should still be a bug.

PS, one of the strengths of THINK is its usefulness in a teaching environment.
How about optional warning of "variable used before initialized," and some of
the other very useful warnings of MPW C?  It catches *me* every so often, and
I've been doing Mac programming in C since SUMACS days.

-Bill Hofmann










Path: ucivax!gateway
From: [e-mail] (Network News)
Subject: (none)
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 59
Date: 26 May 92 18:31:09 GMT

Newsgroups: mail.think-c
Path: nagel
From: [e-mail] (Mark Nagel)
Subject: Re: 'unsubscribe' noise
Message-ID: <[e-mail]>
Sender: [e-mail] (Network News)
Nntp-Posting-Host: elvis
Organization: CIGNA FIRST, Irvine, CA
References: <[e-mail]>
Date: Tue, 26 May 1992 17:47:14 GMT
Lines: 47

In <[e-mail]> Rich Siegel <[e-mail]> writes:

>It seems that many people know to mail to think-c-request to subscribe,
>but to unsubscribe, they always seem to mail to think-c, with the results
>we all know about.

It is a problem, and I wish I had a software solution to it.  In
some list management systems, you can specify simple patterns to
check for which trigger an automatic rejection of the message.  The
list software on ics.uci.edu does not have this feature and I'm no
longer in a position to modify it...

>The course of action I suggest is this: if an unsubscribe request goes out
>to the general list, it will not be acted upon, and the readers of the list
>(or some subset thereof) will send a message to the originator advising him
>that administrative requests should go to think-c-request, not to think-c.
>This has two benefits: novices reading the list (and considering unsubscribing)
>will be repeatedly reminded of the correct mechanism, and the person who
>asked to unsubscribe will (hopefully) get the message and use the correct
>mechanism.

I have always ignored administrative messages on the list itself
figuring that what you describe will occur.  For some reason, people
must either forget what I sent to them when they joined the list or
not even read it to begin with.  Perhaps I need to post a reminder.
I'm not sure it would work, since the offenders would probably fail
to read that as well.

I would also like to apologize in advance to anyone who feels they
are getting unacceptably slow response times from me when they
submit requests to think-c-request.  I am no longer at UCI and have
few occasions to login during my normal work hours.  I tend to login
about three times per week and just handle all requests when I get
there.  So if you think I'm ignoring you, I'm not :)

As far as the archives go, I believe I'll have no problem keeping
them there even though I no longer work at UCI unless something
unusual occurs.  If that ever does happen, I might request that the
list be moved to a different location.  I could move it here, but we
are not on the net which would greatly increase redistribution times
and prevent ftp access.

Mark
--
Mark Nagel <[e-mail]>    | DISCLAIMER: If you had all of CIGNA's
Network Administrator        | in a container, you would not find mine
CIGNA/FIRST            | in that container.










Path: ucivax!gateway
From: [e-mail] (MIKOLIC-TORREI I)
Subject: Other ThC wish-list items...
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 34
Date: 26 May 92 18:44:10 GMT


Bill Hofmann recently said:
>How about optional warning of "variable used before initialized," and some of
>the other very useful warnings of MPW C?

Can't agree more.  I'd also like to add the following "how about" items:

"variable declared but never used" -- after I optimize (er, okay, clean-up)
a function, I tend to have a few of these around.  Be nice to have the
compiler warn me (if I so choose).

"generate a list of errors (vice one at a time)" -- Turbo C v2 implemented
this quite nicely on the PC.  One window had a list of errors, if you
selected an error, your code window automatically scrolled to and highlighted
the offending line.  Having a super-fast comiler isn't so useful if you
compile the first half of your file 10^6 times while catching all the silly
typo-type errors.  Then again, I'm probably the only one who ever makes
typos in abundance :)

"value may be altered in conversion" -- I sometimes get a bit careless (and
even a bit confused at times) going back and forth between short and long,
signed and unsigned.  Some compilers would warn you whenever a bigger type
was squeezed into a "smaller" type (Turbo C in particular would).  Usually
I knew what I was doing, but saved me from myself on more than one occasion.

There are others, but I won't remember them until the next time
compile/debug something...

None of these are "must haves", but it would be nice (i.e., save time and
fustration) to be able to turn them on when you wanted them.  They would
make ThC a better product.

Igor Mikolic-Torreira











Path: ucivax!gateway
From: [e-mail] (Bob Miller)
Subject: Re: Think C 5.0.2 vs. TMON Pro 3.0 reprise
Message-ID: <9205261855.AA07376@Mr_Grape.convex.com>
In-Reply-To: Your message of "24 May 92 15:14:23 GMT."
             <[e-mail]>
Newsgroups: fa.think-c
X-Quote-Of-The: There's a young kid inside me somewhere
                Who stays up all night, a vampire that never dies.
                I hear his voice when I'm coming down.
                "Sleep is for fools, who never see the sunrise,
                Who never get to live twice."  -- John Entwhistle
Lines: 11
Date: 26 May 92 19:50:50 GMT

> Given that you have the address of the jump table entry, and given
> that it's a loaded entry, you can probaby use an expression like:
>
>     *(Ptr *)((char *)&main + 4) // should return "real" address of main
>
> (off the top of my head, no guarantees)

I think it should be "+ 2", not "+ 4".  The JMP opcode
is only two bytes.

                    K<bob>










Path: ucivax!gateway
From: [e-mail] (Michael Perrone)
Subject: Re: Other ThC wish-list items...
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>; from "MIKOLIC-TORREI I" at May 26, 92 6:44 pm
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: fa.think-c
Lines: 23
Date: 26 May 92 21:05:18 GMT

MIKOLIC-TORREI I writes:
>
>
> Bill Hofmann recently said:
> >How about optional warning of "variable used before initialized," and some of
> >the other very useful warnings of MPW C?
>
> Can't agree more.  I'd also like to add the following "how about" items:
>
> "variable declared but never used" -- after I optimize (er, okay, clean-up)
> a function, I tend to have a few of these around.  Be nice to have the
> compiler warn me (if I so choose).
[...]

What this really comes down to is that a "lint" is needed for Think C.
I would really like that, myself.

***********************************************/
* Michael Perrone   *   Programmer/Analyst     *
* Portland State University, Portland OREGON   *
* INTERNET          [e-mail]       *
* VOICE  [phone]  FAX [phone]    *
***********************************************/










Path: ucivax!gateway
From: [e-mail] ("Edward J. Huff")
Subject: think-c-request and other useful information
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 105
Date: 27 May 92 04:42:30 GMT
X-Envelope-to: [e-mail]

Here is a copy of the form letter I (usually) send out when
I receive a subscribe or unsubscribe request on the think-c
list.  I was out of town for the past week and did not send
this for most of the recent spate of unsubscribe request.

You might find some new information here.  Is the mailing
list charter up to date?

Subject:  Please send requests to [e-mail]

Most mailing lists with address "xxx@yyy" have an associated address
"xxx-request@yyy" which is used for requests about your subscription, so
that everyone on the list doesn't have to read about your subscription.

The following can be found in "Publicly Accessible Mailing Lists, Part
III", which is periodically posted to news.announce.newusers.  If it is
expired at your site, you can obtain it by anonymous FTP or mail server
from site PIT-MANAGER.MIT.EDU.  More information on how to do this is given
below.

think-c
    Contact: [e-mail]  (Mark Nagel)

    Purpose: This list exists to discuss the Think C compiler for the
    Macintosh.  Acceptable topics include discussion of compiler
    problems and solutions/workarounds, discussion of object-oriented
    programming and Macintosh programming, and the sharing of source
    code.  Associated with this list is an archive stored on
    ics.uci.edu accessible via ftp and a mail archive server
    ([e-mail]).  Submissions to the archive should
    go to think-c-request.


This came from "Answers to Frequently Asked Questions" in the USENET
newsgroup news.announce.newusers:

30.  How do I contact the moderator of an Internet mailing list rather than
     post to the entire list?

     To do this you should know that there are, by convention, two
     mailing addresses for every mailing list (except where noted by
     the List of Lists):

         list@host        (e.g. [e-mail])
         list-request@host    (e.g. [e-mail])

     When you have something for everyone on the mailing list to read,
     mail to the list@host address. HOWEVER, if you have an
     administrative request to make (e.g. "please add me to this list",
     "please remove me from this list", "where are the archives?",
     "what is this mailer error I got from sending to this list?"), it
     should be directed to the list-request@host address, which goes
     only to the mailing list administrator.

     It is considered to be in bad taste to send administrative
     requests to the entire mailing list in question, and if (as is
     often the case) the administrator does not read the mailing list
     (i.e. he just takes care of the admin tasks for the list), he will
     not see your request if you don't send it to the right address.


This came from "List of Periodic Informational Postings" in
news.announce.newusers:

3/21/90

Jonathan Kamens of MIT's Project Athena has kindly set up an archive of
periodic postings; the archive is constructed by a shell script which reads
this article, using it as a guide as to which postings should be archived.
What follows is a condensed excerpt of his article announcing this
archive...

This archive is on "pit-manager.mit.edu" (18.72.1.58), and is accessible
via anonymous ftp in the directory "/pub/usenet".  The structure of this
directory is such that each subdirectory is a newsgroup name, and the files
in the subdirectories are the periodic postings.  The filenames are
constructed by mapping the titles to filenames in a pretty simple way, e.g.

/pub/usenet/news.announce.newusers/Answers_to_Frequently_Asked_Questions

The archive is also accessible via mail archive server.  The address of the
server is [e-mail].  The names are the same, with
the "/pub/" chopped off.  To retrieve the file mentioned above, you would
send mail to the mail-server with a subject or body of

send usenet/news.announce.newusers/Answers_to_Frequently_Asked_Questions

You can also do "send help", "send index", "send usenet/index", "send
usenet/news.announce.newusers/index", etc.

Comments, questions, suggestions, etc. can be sent to me at the address
below, or at {root,jik,postmaster,daemon}@pit-manager.mit.edu.  Feel free
to mention this service in any informational postings you may maintain; I
hope to keep it up and running for a while.


Jonathan Kamens          USnail:
MIT Project Athena       11 Ashford Terrace
[e-mail]       Allston, MA  02134
Office: 617-253-8085     Home: 617-782-0710
--
Edward J. Huff   [e-mail]   [phone]
Keck Laboratory for Biomolecular Imaging
NYU Chemistry Deptartment, 31 Washington Place, New York NY 10003











Path: ucivax!gateway
From: [e-mail]
Subject: Segmentation bug -- maybe
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 35
Date: 27 May 92 13:48:53 GMT


I traced down a bug which, although I can pinpoint and even avoid, I still
do not understand.  I wonder if anyone can help.

The symptom was that an important data structure in my program got
clobbered.  I traced it down to a memcpy() call which did not work.  I
single stepped in the debugger, and I am absolutely sure that I supply
perfectly good pointers and byte-count to the procedure.  I tried to
replace memcpy() with strncpy() (I have no zero-bytes in the stuff I am
copying), but that did not help.

The thing that really puzzled me was that the very same memcpy() line, in
the very same procedure, worked fine EVERY TIME EXCEPT THE FIRST.  In other
words, there is something funny about the first time memcpy() or strncpy()
are called.

My first remedy was to replace the memcpy() with a one-line for loop, and
that solved the problem.  But then it occured to me that if there is
something funny about the first time I called an ANSI routine, I might as
well call a dummy ANSI routine once.  So I added the following statement as
the very first statement in my main():

    { char dummy[100];  sprintf(dummy, "load my segment"); }

and restored the memcpy().  Now everything works just fine - memcpy() works
great the first time as well as any other time.

I am using TCL, if that matters, and also I have recompiled ANSI to use the
native floating point mode.  The ANSI library is in a separate segment.


Thank,

Chuck Shavit
[e-mail]










Path: ucivax!gateway
From: [e-mail] (Aaron Wohl)
Subject: Re: Segmentation bug -- maybe
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
Newsgroups: fa.think-c
Lines: 14
Date: 27 May 92 14:51:51 GMT
References: <[e-mail]>

I had the same problem...

The problem is that the segment mempcy is in is not resident.  The first
time it is called it is loaded in cand the segment loader can cause a
garbage collection and move the unlocked dereferenced handle being
passed to memcpy.  Since TCL object are really handles if you are
passing a variable inside an object to memcpy it will do this.

The simplest way around it is to create empty routines:
void load_seg1()
{}

and have one such routine in each segment you want to load at startup.
Aaron










Path: ucivax!gateway
From: [e-mail]
Subject: Segmentation bug -- maybe
Message-ID: <[e-mail]>
In-Reply-To: Aaron Wohl's message of Wed, 27 May 1992 10:49:55 -0400 (EDT) <[e-mail]>
Newsgroups: fa.think-c
Lines: 30
Date: 27 May 92 15:01:30 GMT

> Date: Wed, 27 May 1992 10:49:55 -0400 (EDT)
> From: Aaron Wohl <[e-mail]>
>
> I had the same problem...
>
> The problem is that the segment mempcy is in is not resident.  The first
> time it is called it is loaded in cand the segment loader can cause a
> garbage collection and move the unlocked dereferenced handle being
> passed to memcpy.  Since TCL object are really handles if you are
> passing a variable inside an object to memcpy it will do this.
>
> The simplest way around it is to create empty routines:
> void load_seg1()
> {}
>
> and have one such routine in each segment you want to load at startup.
> Aaron
>

Thank, Aaron.

BTW, are there conditions in which TC or Mac O/S decide to unload a
segment?  If so, is there a way to lock segments like the ANSI library in
place?

I just thought of another way to load the ANSI segment: have my main()
code, which is rather small, reside in the same segment as ANSI.  I'll try
that tonight.

Chuck Shavit










Path: ucivax!gateway
From: [e-mail] ("Jamie R. McCarthy")
Subject: Re: Segmentation bug -- maybe
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>; from "[e-mail]" at May 27, 92 1:48 pm
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: fa.think-c
Lines: 16
Date: 27 May 92 15:43:46 GMT

> The symptom was that an important data structure in my program got
> clobbered.  I traced it down to a memcpy() call which did not work.  I
> single stepped in the debugger, and I am absolutely sure that I supply
> perfectly good pointers and byte-count to the procedure.
>
> The thing that really puzzled me was that the very same memcpy() line, in
> the very same procedure, worked fine EVERY TIME EXCEPT THE FIRST.
> ... The ANSI library is in a separate segment.

That memory that you're coping to--is it in an unlocked handle?  If the
segment with the ANSI library needs to be loaded in, the call to
memcpy() could well move memory.
--
 Jamie McCarthy     Internet: [e-mail]     AppleLink: j.mccarthy
 "Also thanks to:  Inside Macintosh (except vol. V, ch. 27)"
   - the Tesserae "About..." box










Path: ucivax!gateway
From: [e-mail] (Craig Hollabaugh)
Subject: Re:  Segmentation bug -- maybe
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 9
Date: 27 May 92 15:49:39 GMT


>The thing that really puzzled me was that the very same memcpy() line, in
>the very same procedure, worked fine EVERY TIME EXCEPT THE FIRST.  In other
>words, there is something funny about the first time memcpy() or strncpy()
>are called.

I've experienced the same problem also, except I was using printf(). So
you are not going crazy. Unfortunately I can't offer any suggestions.











Path: ucivax!gateway
From: [e-mail]
Subject: Segmentation bug -- maybe
Message-ID: <[e-mail]>
In-Reply-To: Jamie R. McCarthy's message of Wed, 27 May 92 11:45:19 EDT <[e-mail]>
Newsgroups: fa.think-c
Lines: 37
Date: 27 May 92 15:56:53 GMT

> From: [e-mail] (Jamie R. McCarthy)
> Date: Wed, 27 May 92 11:45:19 EDT
>
> > The symptom was that an important data structure in my program got
> > clobbered.  I traced it down to a memcpy() call which did not work.  I
> > single stepped in the debugger, and I am absolutely sure that I supply
> > perfectly good pointers and byte-count to the procedure.
> >
> > The thing that really puzzled me was that the very same memcpy() line, in
> > the very same procedure, worked fine EVERY TIME EXCEPT THE FIRST.
> > ... The ANSI library is in a separate segment.
>
> That memory that you're coping to--is it in an unlocked handle?  If the
> segment with the ANSI library needs to be loaded in, the call to
> memcpy() could well move memory.
> --
>  Jamie McCarthy     Internet: [e-mail]     AppleLink: j.mccarthy
>  "Also thanks to:  Inside Macintosh (except vol. V, ch. 27)"
>    - the Tesserae "About..." box
>

Yes indeed.  I guess I was not aware of the fact that segment loading can
happen when I am not expecting it, and that it can move memory under me.

Of course, I use memcpy() and not a simple for loop because I want speed,
so it does not make sense to me to lock the handle before memcpy() and
unlock it afterwards.  I think that my solution -- to cause the ANSI
segment to load before I first use it -- is the right one.

Which brings the following question -- if I pass a dereferenced (unlocked)
handle to a function, how can I ensure that the function I am calling is
resident in core?  I guess the case of TCL methods is easier, because when
you access a method you must have created the object beforehand, and in
most cases you have a constructor which resides in the same segment as the
method.  But what about other functions?

Chuck Shavit










Path: ucivax!gateway
From: [e-mail] (Rich Siegel)
Subject: Re:  Segmentation bug -- maybe
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 7
Date: 27 May 92 16:22:47 GMT

If the source or target of your memcpy() is in a relocatable block (allocated
by NewHandle()), then it very likely will move when a code segment gets
loaded. To avoid bugs like this, you should lock your relocatable blocks
before computing pointers into them, if you're planning to call any routines
that could move memory.

R.










Path: ucivax!gateway
From: [e-mail] ("Jamie R. McCarthy")
Subject: Re: Segmentation bug -- maybe
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>; from "[e-mail]" at May 27, 92 11:57 am
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: fa.think-c
Lines: 66
Date: 27 May 92 16:32:39 GMT

[e-mail] writes:
> > From: [e-mail] (Jamie R. McCarthy)
> > [chuck writes:]
> > > The thing that really puzzled me was that the very same memcpy() line, in
> > > the very same procedure, worked fine EVERY TIME EXCEPT THE FIRST.
> > > ... The ANSI library is in a separate segment.
> >
> > That memory that you're coping to--is it in an unlocked handle?  If the
> > segment with the ANSI library needs to be loaded in, the call to
> > memcpy() could well move memory.
>
> Of course, I use memcpy() and not a simple for loop because I want speed,
> so it does not make sense to me to lock the handle before memcpy() and
> unlock it afterwards.

How much memory are you copying?  If it's more than a few hundred bytes,
the copy will take much longer than the locking/unlocking will.  If it's
not, don't worry about speed!  :-)

Seriously, the only way that the HLock/HUnlock should cause any
noticeable delay is if it's called within an oft-repeated loop.  Now,
either this loop (excepting any segment loading) can move memory or it
can't.  If it can't, call HLock before and HUnlock after, and don't
worry about possible memory management inefficiencies, because there
won't be any.  If it _can_, any memory move might take much longer than
your memcpy(), and certainly longer than a few thousand HLock/HUnlock's.

So if the loop can move memory:

for (i = 0; i < LARGENUMBER; ++i) {
    HLock(theHndl);
    memcpy(source, *theHndl, bytes);
    HUnlock(theHndl);
    possibleMemoryMovingFunction();
}

...and if it can't:

HLock(theHndl);
for (i = 0; i < LARGENUMBER; ++i) {
    memcpy(source, *theHndl, bytes);
    nonMemoryMovingFunction();
}
HUnlock(theHndl);

You might want to MoveHHi(theHndl), too, so there's little chance of the
loading of the segment interfering with it.  (The Segment Loader tries
its best to get 'CODE' resources low in the heap.)
> I think that my solution -- to cause the ANSI
> segment to load before I first use it -- is the right one.

But then you can't ever unload it again.  Which is fine if you're not in
a memory squeeze...but if you are, it's nice to be able to dispose of
unneeded segments.  This kind of memory-management is something you have
to design from the start;  you can't add it on a week before you ship.

> if I pass a dereferenced (unlocked)
> handle to a function, how can I ensure that the function I am calling is
> resident in core?

Hmmmm...you know, I guess I don't know.  Anyone else?
--
 Jamie McCarthy     Internet: [e-mail]     AppleLink: j.mccarthy
 "A common way to answer a question about C is to 'see what the compiler
  does.'  Clearly C has suffered from being partly defined, then
  implemented."  - High C language reference manual, 1987










Path: ucivax!gateway
From: [e-mail]
Subject: Segmentation bug -- maybe
Message-ID: <[e-mail]>
In-Reply-To: Rich Siegel's message of Wed, 27 May 92 12:22:36 -0400 <[e-mail]>
Newsgroups: fa.think-c
Lines: 19
Date: 27 May 92 17:10:56 GMT

> Date: Wed, 27 May 92 12:22:36 -0400
> From: [e-mail] (Rich Siegel)
>
> If the source or target of your memcpy() is in a relocatable block (allocated
> by NewHandle()), then it very likely will move when a code segment gets
> loaded. To avoid bugs like this, you should lock your relocatable blocks
> before computing pointers into them, if you're planning to call any routines
> that could move memory.
>
> R.
>

Thanks Rick.

I am not sure the problem is neccasarily related to memory moving
procedures - I bet things like strlen() could be led astray in much the
same way.

Chuck










Path: ucivax!gateway
From: [e-mail] (The sky is ecstasy dancing)
Subject: what exactly are segements...
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 19
Date: 27 May 92 17:48:28 GMT
X-Vmsmail-To: SMTP%"[e-mail]"

Ok,
  I have been reading the Think C manual (oh my god what is the world coming
to? someone reading a manual??? :)), and they keep bringing up the 32k segement
size.  And well, I am not really sure why this magic number is used.  I haven't
read the complete set of IM, but of the ones that I have read, I don't recall
this "limitation" if it is one.

  Could someone explain it to me, or point me in the right direction, as to
where I can find the answer?

Thanks,

Mike

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Mike Ruhl
Operator/mac learner..
Arizona Cancer Center
[e-mail]










Path: ucivax!gateway
From: [e-mail] (Rich Siegel)
Subject: Re:  Segmentation bug -- maybe
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 10
Date: 27 May 92 18:39:40 GMT

>BTW, are there conditions in which TC or Mac O/S decide to unload a
>segment?

No. Segments are never unloaded without an explicit call to UnloadSeg()
by your application.

Placing the file containing main() in the same segment as ANSI is a fine
idea, and will work correctly.

R.










Path: ucivax!gateway
From: [e-mail] (Kathleen Fischer)
Subject: Re: Segmentation bug -- maybe
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
X-VMS-To: ADDVAX::IN%"[e-mail]"
Lines: 12
Date: 27 May 92 20:14:42 GMT
X-Envelope-to: [e-mail]

>Of course, I use memcpy() and not a simple for loop because I want speed,
>so it does not make sense to me to lock the handle before memcpy() and
>unlock it afterwards.  I think that my solution -- to cause the ANSI
>segment to load before I first use it -- is the right one.

Ok -- I was following this discussion just fine (for a beginner) until the
reference above to _speed_.  Why would locking/unlocking a handle be slow?
Does the memory manager try to compact the space first?  I would think
that locking/unlocking would be much safer than calling the ANSI segment
first.

Kathleen










Path: ucivax!gateway
From: [e-mail]
Subject: MacBinary Source
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 7
Date: 27 May 92 22:27:18 GMT
X-Vmsmail-To: SMTP%"[e-mail]"

I'm writing a BBS host package, and I need some routines to do some MacBinary
conversions. I have looked in all of the sources I know of, and if anyone could
help point me to some Think C-compilable code, I would be greatful.

Thanks.

[e-mail]










Path: ucivax!gateway
From: [e-mail]
Subject: Re: Segmentation bug -- maybe
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 34
Date: 27 May 92 23:59:36 GMT


>Ok -- I was following this discussion just fine (for a beginner) until the
>reference above to _speed_.  Why would locking/unlocking a handle be slow?
>Does the memory manager try to compact the space first?  I would think
>that locking/unlocking would be much safer than calling the ANSI segment
>first.

You are correct in believing that Hlock/Hunlock takes very little time.
They
really only set or unset a bit. It does not do any memory compaction or
movement.(at least it says it doesn't move memory) But you still have the
trap
overhead. Any call to an Atrap is going to take a little extra time because
of
the trap mechanism. (ie find the right address then jump to it or what ever
it
does).

In a tight loop you really don't want to do this if speed is your main
concern.
Its best to call hlock outside of the loop and the hunlock when you exit
the loop. Or if you want to be gutsy you can get the trap address yourself
and jump to it.


Matt
_____________________________________________________________________
   Matthew Xavier Mora                   |  The keeper of the UMPG
   SRI International                     |  [e-mail]
   [sent using Eudora 1.3b34]            |  [e-mail]
_____________________________________________________________________
"You give good headgames, your tongue is so strange, caught in these
 backstage chains." _Crashed_ by Slik Toxik











Path: ucivax!gateway
From: [e-mail] (Peter Miller)
Subject: Re: Segmentation bug -- maybe
Message-ID: <[e-mail]>
In-Reply-To: Your message of 27 May 92 17:10:56 +0000.
             <[e-mail]>
Newsgroups: fa.think-c
Lines: 13
Date: 28 May 92 00:06:38 GMT


[e-mail] writes:
> I am not sure the problem is neccasarily related to memory moving
> procedures - I bet things like strlen() could be led astray in much the
> same way.

this is my
Golden Rule of Mac Programming:

When manipulating dynamic memory contents - Lock Those Handles.

Regards
Peter Miller.










Path: ucivax!gateway
From: [e-mail] (Pete Resnick)
Subject: Re: Segmentation bug -- maybe
Message-ID: <[e-mail]>
X-Mailer: Eudora [version 1.3a39 MacTCP]
Newsgroups: fa.think-c
Lines: 36
Date: 28 May 92 03:41:41 GMT

[e-mail] (Kathleen Fischer) writes:

>Ok -- I was following this discussion just fine (for a beginner) until the
>reference above to _speed_.  Why would locking/unlocking a handle be slow?

Calling any Macintosh Toolbox/OS routine is always going to be slow if
speed is *really* important. Remember that Toolbox calls are traps: that
is, 2 bytes of illegal instruction are inserted into the assembly code that
cause the 680x0 processor to trap to an illegal instruction handler, the
trap table. Every time the processor traps, it has to but the entire world
onto the stack, set up some stuff, use the appropriate value in the trap
table to jump to a routine and then undo everything that it has done.
Something like memcpy() is just a whole lot of MOVE instructions, which
really take no time at all. If this is being called repeatedly in a loop
(let's say you were moving lots of multiple K buffers all over the place),
the locking and unlocking would hurt quite a bit.

[e-mail] (Mike Ruhl) writes:

>  I have been reading the Think C manual (oh my god what is the world coming
>to? someone reading a manual??? :)), and they keep bringing up the 32k segement
>size.  And well, I am not really sure why this magic number is used.  I haven't
>read the complete set of IM, but of the ones that I have read, I don't recall
>this "limitation" if it is one.

I think this is mentioned in the Segment Loader chapter in IM II. The
problem is that 32K of memory is all that you can specify in 2 bytes (16
bits). In the 68000 instruction set, you can only use PC (program counter)
address mode with a 16 bit offset; there is no 32 bit addressing mode. The
biggest number (signed) that you can specify in 16 bits is 32768, hence the
32K limit on any one piece of code.

How's that?

pr











Path: ucivax!gateway
From: [e-mail] (Paul Potts)
Subject: Re: 32K segment size
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 28
Date: 28 May 92 13:14:30 GMT


Pete Resnick <[e-mail]> writes:

>In the 68000 instruction set, you can only use PC (program counter)
>address mode with a 16 bit offset; there is no 32 bit addressing mode.

This is true, but doesn't address the 32K segment size fully. After all,
it is quite possible (and MPW C and THINK C now allow the programmer) to
build code and data in pieces larger than 32K.

There is no intrinsic limit in the 68000 family that say you can only jump
+/- 32K. With the Mac 128, because memory was so tight, the designers wanted
to implement a memory overlay scheme similar to the way DOS programs do it -
with segments loaded and unloaded as needed to conserve space. The 16-bit
PC-relative jump was used because it is also small, tight, and doesn't
require much overhead. (Yes, there is a limit on this particular form of
jump instruction). The standard jump table allows 32K of entry points; using
THINK C's far code option gives you 256K of entry points, enough for quite
a large number of functions or member functions, although the 32-bit
absolute address mode requires more space for each one, I believe. I think
the OS still expects your code to be in 32K segments. That is somewhat of
an anachronism, but the overlay scheme is still useful in tight memory
situations if your application is written to take advantage of it.

I just wanted to point out that the 68000 isn't an 8086 - there aren't
"hard" limits on code and data segments, and no weird memory models that
hinder the programmer. After all, we're all adults here... we don't need
a CPU that is designed for kids!  : )










Path: ucivax!gateway
From: [e-mail] (Paul Potts)
Subject: Re: 32K segment size
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 28
Date: 28 May 92 13:15:34 GMT


Pete Resnick <[e-mail]> writes:

>In the 68000 instruction set, you can only use PC (program counter)
>address mode with a 16 bit offset; there is no 32 bit addressing mode.

This is true, but doesn't address the 32K segment size fully. After all,
it is quite possible (and MPW C and THINK C now allow the programmer) to
build code and data in pieces larger than 32K.

There is no intrinsic limit in the 68000 family that say you can only jump
+/- 32K. With the Mac 128, because memory was so tight, the designers wanted
to implement a memory overlay scheme similar to the way DOS programs do it -
with segments loaded and unloaded as needed to conserve space. The 16-bit
PC-relative jump was used because it is also small, tight, and doesn't
require much overhead. (Yes, there is a limit on this particular form of
jump instruction). The standard jump table allows 32K of entry points; using
THINK C's far code option gives you 256K of entry points, enough for quite
a large number of functions or member functions, although the 32-bit
absolute address mode requires more space for each one, I believe. I think
the OS still expects your code to be in 32K segments. That is somewhat of
an anachronism, but the overlay scheme is still useful in tight memory
situations if your application is written to take advantage of it.

I just wanted to point out that the 68000 isn't an 8086 - there aren't
"hard" limits on code and data segments, and no weird memory models that
hinder the programmer. After all, we're all adults here... we don't need
a CPU that is designed for kids!  : )










Path: ucivax!gateway
From: [e-mail] (Phil Shapiro)
Subject: Segmentation bug -- maybe
Message-ID: <[e-mail]>
In-Reply-To: "Jamie R. McCarthy"'s message of 27 May 92 16:32:39 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 30
Date: 28 May 92 13:19:17 GMT

>>>>> On 27 May 92 16:32:39 GMT, "Jamie R. McCarthy" <[e-mail]> said:

>> if I pass a dereferenced (unlocked) handle to a function, how can I
>> ensure that the function I am calling is resident in core?

 > Hmmmm...you know, I guess I don't know.  Anyone else?

If you take the address of a function, you'll actually get the address
of that function's jump table entry. If you take the address of a
static function, then THINK C will assign it a jump table entry
automatically (I believe a pragma is necessary in MPW C).

If you want to be sure that the jump table entry is loaded, then
you've got to call some function in the segment in question. Typically
programmers create one dummy function per unloadable segment, and use
the dummy function to load or unload a segment.

Most programs don't need to unload segments at all; dummy functions
may still come in handy if you want to ensure that all segments are
loaded at a certain point on your program (such as calling memcpy()
into an instance variable of a handle-based object :).

A great (although getting on in years) book on this topic is Scott
Knaster's "How to Write Macintosh Software".

    -phil
----
   Phil Shapiro                                   Software Engineer
   Language Products Group                     Symantec Corporation
           Internet: [e-mail]










Path: ucivax!gateway
From: [e-mail]
Subject: Segmentation bug -- maybe
Message-ID: <[e-mail]>
In-Reply-To: Kathleen Fischer's message of 27 May 92 20:14:42 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 69
Date: 28 May 92 14:18:52 GMT

> From: Kathleen Fischer <[e-mail]>
> X-Vms-To: ADDVAX::IN%"[e-mail]"
> Date: 27 May 92 20:14:42 GMT
> X-Envelope-To: [e-mail]
>
> >Of course, I use memcpy() and not a simple for loop because I want speed,
> >so it does not make sense to me to lock the handle before memcpy() and
> >unlock it afterwards.  I think that my solution -- to cause the ANSI
> >segment to load before I first use it -- is the right one.
>
> Ok -- I was following this discussion just fine (for a beginner) until the
> reference above to _speed_.  Why would locking/unlocking a handle be slow?
> Does the memory manager try to compact the space first?  I would think
> that locking/unlocking would be much safer than calling the ANSI segment
> first.
>
> Kathleen
>

My guess is the locking/unlocking is done efficiently and does not take too
much time.


I would like to take back some of what I said about speed, though.  Jamie
R. McCarthy wrote what I thought was a very true statement:

  > How much memory are you copying?  If it's more than a few hundred bytes,
  > the copy will take much longer than the locking/unlocking will.  If it's
  > not, don't worry about speed!  :-)

There are three issues here:

  * Speed: If the speed of a given program segment is important, there are
    many ways to optimize it (read the last Develop for an excellent
    description of speeding up a bitmap manipulating code).  Generally (but
    not necessarily), the more optimized a code is, the uglier it gets, and
    also less safe, which brings up the second issue:

  * Safety: programs should be not only "correct", but also safe.  One
    should program using lots of sanity checks (use ASSERT()), not only
    because it helps debug the program, but also because it helps maintain
    it in future revisions.  In our case, safety requires locking before
    and unlocking after: although you THINK that a given pointer is safe,
    you may be wrong.  I was wrong, as you know.

  * Ease of programming: some of us programmers try to make the program
    shorter and cleaner for no good reason other then our laziness (and
    some would say, a sense of esthetics).  "Short and clean" also means
    that someone else can dive into the code faster.  That someone else may
    be you, 6 months older.

The reason I used memcpy() was the third.  Memcpy() simply has that concise
touch to it, even more then a for loop.

The reason I refuse to lock my handles before calling memcpy() is that it
feels stupid IMHO to enclose every call to every ANSI procedure with
lock/unclock just because the very first time ANSI is loaded, memory moves
under you.  Lock/unclock requires to make the elegant memcpy() call a five
statement monster.  Since I now understand, thanks to the think-c netters,
what I did wrong, and since I understand how to make sure ANSI is loaded
before I first use it, I see no reason to lock.

If someone from Symantec is listening: could you guys come up with an easy
interface to mark a segment code resource as preloaded?  I was thinking
about a toggle much like toggling the debug flag of a module.  In the era
of Megabyte = $30, I would not mind if all the segments are preloaded by
default.

Chuck Shavit










Path: ucivax!gateway
From: [e-mail] (Paul Potts)
Subject: double posting
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 3
Date: 28 May 92 15:16:00 GMT

Apologies for the double posting. I got a bounce message the first time
and reposted, but apparently it went through despite the bounce message.
-Paul-










Path: ucivax!gateway
From: [e-mail] (Steven Cantor)
Subject: Re: Segmentation bug -- maybe
Message-ID: <[e-mail]>
In-Reply-To: Your message of 28 May 92 13:19:17 GMT
Newsgroups: fa.think-c
Organization: Harvard University
X-Acknowledge-To: <SLC@HARVARDA>
Lines: 14
Date: 28 May 92 16:26:28 GMT

On 28 May 92 13:19:17 GMT Phil Shapiro said:
>A great (although getting on in years) book on this topic is Scott
>Knaster's "How to Write Macintosh Software".
>
  isn't a new edition of this book imminent?
  s.

-------------------------------------------------------------------------
Steven Cantor
Information Resources and Services  INTERNET:[e-mail]
Harvard University                  BITNET:  [e-mail]
 _________                                                 ____________
          the wild geese do not intend to cast their shadow
          the water has no mind to receive their image










Path: ucivax!gateway
From: [e-mail]
Subject: Re: double posting
Message-ID: <9205281651.AA25570@orwell>
Newsgroups: fa.think-c
Reply-To: [e-mail]
Lines: 19
Date: 28 May 92 17:07:51 GMT
References: <[e-mail]>

In mail.think-c, Paul Potts <[e-mail]> writes:

>Apologies for the double posting. I got a bounce message the first time
>and reposted, but apparently it went through despite the bounce message.

People who mail to think-c should never see bounces due to
undeliverable mail to other list members.  Unfortunately, some sites
have broken mailers that ignore the message envelope and instead
send errors to the person mentioned in the 'From:' line.  This is
completely erroneous behavior.  I will not keep such addresses in
the list.  If you do get such a bounce, please send the complete
bounced message with errors and all to [e-mail].
I will ZOT the addresses ASAP.

Mark
--
Mark Nagel <[e-mail]>    | DISCLAIMER: If you had all of CIGNA's
Network Administrator        | in a container, you would not find mine
CIGNA/FIRST            | in that container.










Path: ucivax!gateway
From: [e-mail] (Paul Potts)
Subject: Re: double posting
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 14
Date: 28 May 92 19:58:52 GMT


We should really kill this subject to stop wasting everyone's time, but I
thought I should mention that I found the problem... it was a typo on my
part. I typed "mail mail [e-mail]." The mail program immediately
generated a bounce message from my own host. I thought I must have made a
typo in the address "[e-mail]" so I sent the message again. What
actually happened, as you can guess, is that the mail program gagged on
mailing to "mail," bounced the message back to me, but sent it correctly
to the second recipient ([e-mail]). That's what I get for looking
away from the screen for a minute in the middle of typing a command. So,
it isn't anyone else's mailer or mine that is broken, it's my brain.

Sorry for the wasted bandwidth (and everybody's disk space...)
-Paul-










Path: ucivax!gateway
From: [e-mail] ("Hisham A. Abboud")
Subject: summer jobs
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 14
Date: 28 May 92 21:12:43 GMT


I am looking for a sophomore/junior student to work for this summer (and
possibly part time in the fall) to do Mac programming using Think C.
Anyone interested or know someone interested?  Cedrus is located in
Columbia, Maryland.  Please e-mail me or call at [phone].

Thanks!

                        Hisham.


Hisham A. Abboud, Cedrus Corp.  [Internet: [e-mail]]












Path: ucivax!gateway
From: [e-mail] (King Rhoton)
Subject: Re:  summer jobs
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 1
Date: 29 May 92 02:57:20 GMT












Path: ucivax!gateway
From: [e-mail] (Bob Miller)
Subject: More HLock/memcpy fu
Message-ID: <9205290434.AA22827@Mr_Grape.convex.com>
Newsgroups: fa.think-c
Lines: 144
Date: 29 May 92 04:35:19 GMT

Isn't this horse dead yet?

I was curious about how fast/slow HLock(), HUnlock() and memcpy()
really are, so I wrote a program to measure them.  Good time to learn
something about the Time Manager.  (Hey, it's a great manager!  A
nominee for Best-Implemented Low Level Feature.)

Anyway, I wrote a program, and I ran it on my IIsi (sans accelerators :-( ).
Here are the timings.

(Yow!  I just ran this stuff again while ZTerm is running, and everything
is half as fast!  The following numbers are while ZTerm is off.)


128 microseconds to HLock/HUnlock.
    16-byte memcpy: 0.964587 megabytes/second
    32-byte memcpy: 1.11438 megabytes/second
    64-byte memcpy: 1.1915 megabytes/second
   128-byte memcpy: 1.24224 megabytes/second
   256-byte memcpy: 1.22066 megabytes/second
   512-byte memcpy: 1.23797 megabytes/second
  1024-byte memcpy: 1.24663 megabytes/second
  2048-byte memcpy: 1.25081 megabytes/second
  4096-byte memcpy: 1.25291 megabytes/second
  8192-byte memcpy: 1.25345 megabytes/second
 16384-byte memcpy: 1.25279 megabytes/second
 32768-byte memcpy: 1.25375 megabytes/second
 65536-byte memcpy: 1.25419 megabytes/second
131072-byte memcpy: 1.26857 megabytes/second
262144-byte memcpy: 1.17805 megabytes/second

                    K<bob>

(Compiled as application with 1000K partition, global optimization off)
------------------------------------------------------------------------------
#include <stdio.h>
#include <string.h>

#define REPEAT_COUNT 10000L
#define MIN_BLOCK_SIZE 16
#define MAX_BLOCK_SIZE (256 * 1024L)    /* 256 Kb */
#define TOTAL_COPY (4 * 1048576L)    /*   4 Mb */
TMTask task;

static void start_timer(void)        /* Start measuring elapsed time. */
{
    task.qLink = nil;
    task.qType = 0;
    task.tmAddr = 0;
    task.tmCount = 0;
    InsTime(&task);
    PrimeTime(&task, 0x80000000);

}

static long stop_timer(void)        /* Stop measuring elapsed time. */
{
    RmvTime(&task);
    return task.tmCount - 0x80000000;    /* return time elapsed. */
}

static void measure_locks(void)
{
    long gross, tare, net;        /* all in microseconds */
    Handle h = NewHandle(1);
    long i;

    /* Make sure relevant parts are resident. */

    HLock(h); HUnlock(h);

    /* Measure overhead. */

    start_timer();
    for (i = 0; i < REPEAT_COUNT; i++)
        ;
    tare = stop_timer();

    /* Measure lock/unlock time */

    start_timer();
    for (i = 0; i < REPEAT_COUNT; i++)
    {
        HLock(h);
        HUnlock(h);
    }
    gross = stop_timer();

    /* Print results. */

    net = gross - tare;
    printf("%ld microseconds to HLock/HUnlock.\n", net / REPEAT_COUNT);
}

static void measure_copy(void)
{
    long gross, tare, net;        /* all in microseconds */
    size_t block_size;
    long n_copies;
    long i;
    void *src, *dst;

    for (block_size = MIN_BLOCK_SIZE; block_size <= MAX_BLOCK_SIZE; block_size <<= 1)
    {
        n_copies = TOTAL_COPY / block_size;
        src = NewPtr(block_size);
        dst = NewPtr(block_size);

        /* Touch every page of src and dst to make sure they're resident. */

        for (i = 0; i < block_size; i += 1000)
            ((char *) dst)[i] = ((char *) src)[i];

        /* Measure overhead. */

        start_timer();
        for (i = 0; i < n_copies; i++)
            ;
        tare = stop_timer();

        /* Measure copying time. */

        start_timer();
        for (i = 0; i < n_copies; i++)
            memcpy(dst, src, block_size);
        gross = stop_timer();

        /* Free memory and print results. */

        DisposePtr(src);
        DisposePtr(dst);
        net = gross - tare;
        printf("%6ld-byte memcpy: %g megabytes/second\n", block_size,
               TOTAL_COPY / 1048576 / ((float) net / 1000000));
    }
}

main()
{
    measure_locks();
    measure_copy();
}












Path: ucivax!gateway
From: [e-mail] (Paul Franklin)
Subject: Re: MacBinary Source
Message-ID: <[e-mail]>
In-Reply-To: Your message of 27 May 92 22:27:18 +0000.
             <[e-mail]>
Newsgroups: fa.think-c
Lines: 12
Date: 30 May 92 10:14:44 GMT

Your message dated: 27 May 92 22:27:18 GMT
>I'm writing a BBS host package, and I need some routines to do some MacBinary
>conversions. I have looked in all of the sources I know of, and if anyone could
>help point me to some Think C-compilable code, I would be greatful.
>
Look on sumex for a variety of files for converting MacBinary stuff, in the
unix dir.  They aren't Think-C, but as long as you replace the calls
to file open/read/write/close, they will probably do the work quite nicely.
And, since they have to work under lots of unix versions, they should
work on Mac's since they need to be byte sixe/order independent.

--Paul Franklin ([e-mail])










Path: ucivax!gateway
From: [e-mail] ("Jamie R. McCarthy")
Subject: Opening source files without following the path
Message-ID: <[e-mail]>
X-Mailer: ELM [version 2.3 PL11]
Newsgroups: fa.think-c
Lines: 19
Date: 30 May 92 14:33:21 GMT

I just, for the umpteenth time, did something I suspect a lot of other
people do:  when I want to open a source/header file quickly, I create a
new document, type in the file's name, select it, and do cmd-D for "Open
Selection".  (That is the standard key, right?  I've put a lot of
command keys in.)

For some reason, it suddenly occurred to me that it would be nice to
have a separate menu item for "Open... And Let ThC Search The Directory
Trees For You," instead of having to go through the five extra steps.
Just hit cmd-something, it brings up a dialog, type in the name, hit
return, it puts away the box, and brings up the file for you.

Someone please put this in the next version, right underneath "Open
Selection."  You'll make me very happy.
--
 Jamie McCarthy     Internet: [e-mail]     AppleLink: j.mccarthy
 "A common way to answer a question about C is to 'see what the compiler
  does.'  Clearly C has suffered from being partly defined, then
  implemented."  - High C language reference manual, 1987










Path: ucivax!gateway
From: [e-mail] (The sky is ecstasy dancing)
Subject: Thanks. :)
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 3
Date: 31 May 92 03:37:22 GMT
X-Vmsmail-To: SMTP%"[e-mail]"

Thanks to all that explained what the 32k segementation was all about.

Mike










Path: ucivax!gateway
From: [e-mail] (Lars Petrus)
Subject: Search File & Open
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 19
Date: 31 May 92 11:34:03 GMT

 Jamie McCarthy     Internet: k044477Ikzoo.edu     AppleLink: j.mccarthy
>For some reason, it suddenly occurred to me that it would be nice to
>have a separate menu item for "Open... And Let ThC Search The Directory
>Trees For You," instead of having to go through the five extra steps.
>Just hit cmd-something, it brings up a dialog, type in the name, hit
>return, it puts away the box, and brings up the file for you.
>
>Someone please put this in the next version, right underneath "Open
>Selection."  You'll make me very happy.

   Nice idea, but I think it would be much better if this function
appeared when "Open Selection" is chosen *without* a selection! This means
that it will still be cmd-D (there are no free cmd keys anyway), and that
there won't be one more ugly and confusing menu item.
   To be real cute, the menu item should change to "Search File & Open..."
when there is no selection.

"Madness is the first sign of dandruff" |   Email:   [e-mail]
   - Dr Winston O'Boogie                |   Reality: Lars Petrus, Solna, Sweden










Path: ucivax!gateway
From: [e-mail] (Jim O'Dell)
Subject: Opening source files without following the path
Message-ID: <[e-mail]>
In-Reply-To: "Jamie R. McCarthy"'s message of 30 May 92 14:33:21 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 23
Date: 31 May 92 14:50:12 GMT


I just, for the umpteenth time, did something I suspect a lot of other
people do:  when I want to open a source/header file quickly, I create a
new document, type in the file's name, select it, and do cmd-D for "Open
Selection".  (That is the standard key, right?  I've put a lot of
command keys in.)

For some reason, it suddenly occurred to me that it would be nice to
have a separate menu item for "Open... And Let ThC Search The Directory
Trees For You," instead of having to go through the five extra steps.
Just hit cmd-something, it brings up a dialog, type in the name, hit
return, it puts away the box, and brings up the file for you.

Someone please put this in the next version, right underneath "Open
Selection."  You'll make me very happy.
-----------------
Also, how about being able to select an item that has been #defined in
some include file and have think C be able to look it up. I'd love that
feature also.

Jim